Why 2.1 is delayed for so long

[Werner Koch]

On Sat, 20 Sep 2014 13:49, infinity0 at pwned.gg said:

> But maybe a future one will want a separate pool for secret keys. So
> it would be good to add a --auto-launch-agent option, to automatically
> launch a new gpg-agent if the current one has a different --homedir.

This is exactly what already happens.

> At least, the manual page should be updated to say --secret-keyring is now ignored (and to point to the new location).

Change to:

    --secret-keyring file

              This is an obsolete option and ignored.  All secret keys
              are stored in the 'private-keys-v1.d' directory below the
              GnuPG home directory.

> Yes, this is gpg-agent 2.1. I'm using --edit-key --expert then
> addkey. It prompts me for a passphrase for each new subkey.

Okay, that is a different thing.  I do not think that caching is needed
for adding a new subkey.  You usually don't add several subkeys and in
any case it helps to remember the passphrase.

> Well, at least it should say the keyid, whether it is a subkey (what use-flags) and (if so) which master key it belongs to?

Why?  You already told gpg what to create.

> I like the gpg 1.4 prompt - it's informative, when I sign something and it prompts me to unlock, it says:
>
> "You need a passphrase [...] for user <UID>, 4096 RSA, subkey $ID, created $date (main keyid $ID)."

This is what I see on my system.  See g10/passphrase.c:gpg_format_keydesc.

  desc = xtryasprintf (_("%s\n"
                         "\"%.*s\"\n"
                         "%u-bit %s key, ID %s,\n"
                         "created %s%s.\n%s"),
                       prompt,
                       (int)uidlen, uid,
                       nbits_from_pk (pk), algo_name,
                       keystr (pk->keyid), timestr,
                       maink?maink:"", trailer);

> Previously (with gpg 1.4) it contained the actual
> documentation. Perhaps Debian should just package the manual.

The manual is build by default. Debian should install it; after all it
is one of the very few GNU manuals which does not use the FDL at all (it
is GPLv3).

> With gpg 1.4 (and it seem the case for 2, [2]), there was a bunch of things stopping me from writing this script [1] using batch mode. The main blocker was:
>
>      Subkey-Type: <algo-number>|<algo-string>
>         This generates a secondary key.  Currently only one subkey
>         can be handled.

You mean, "only one subkey"?  Enter a feature request into the BTS, but
given that this is rarely used I can't promise that I will implement it
any time sonn.  See also the recent discussion on whether to add
--quick-gen-subkey.

> OK, my motivation was that not having a prompt makes the input flow
> more consistent, so easier to script with. But probably the best
> solution is to fix batch mode (and maybe make it work for an existing
> key) rather than to make the CLI "more scriptable".

You can easily script it.  --command-fd/status-fd are your friends.  It
you see an unknown prompt, send a LF and the default action will be
used.

> At least, the (9) ECC option should make it clear there are two keys being made. As dkg pointed out, it is extra confusing when mixed with (10) and (11).

>     (9) ECC and ECC

Good suggestion.  Done.

> There is no way to "go back" in the CLI, so I have to quit the whole
> program if I pick the wrong option. Maybe then we can add a "back"
> option?

Hey, it is for experts ;-)

> That is true, and I can use ElGamal in the meantime.

Use RSA instead.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.