Why 2.1 is delayed for so long
wk at gnupg.org
Sat Sep 20 15:17:03 CEST 2014
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).
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"
"%u-bit %s key, ID %s,\n"
nbits_from_pk (pk), algo_name,
keystr (pk->keyid), timestr,
> 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
> With gpg 1.4 (and it seem the case for 2, ), there was a bunch of things stopping me from writing this script  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
> 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
> 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"
Hey, it is for experts ;-)
> That is true, and I can use ElGamal in the meantime.
Use RSA instead.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel