Why 2.1 is delayed for so long

[Ximin Luo]

On 20/09/14 14:17, Werner Koch wrote:
> 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.
> 

As I observe, if the current GPG_AGENT_INFO has a different homedir from GNUPGHOME, gpg2 will happily use that agent, rather than starting up a new one for the current GNUPGHOME. 

>> 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.
> 

Sounds good.

>> 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.
> 

From a script or program or batch mode generation, the user might not have any notice on what the program is trying to do. So gpg-agent should still display this information.

>> 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);
> 

Yes, the good case is for signatures in GPG 1.4. I'm saying the bad case for key creation in GPG 2.1 should be like the good case, as discussed above.

For GPG 2.1, key creation only says "Please enter the passphrase to protect your new key".

>> 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.
> 

I guess it's rarely used because it's not useful? The case where batch mode is needed most (for complex key creation) is not supported by it!

>> 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.
> 

I am already doing this. Scripting the CLI is awkward and annoying, and the source code ends up giving no indication to the user what is actually happening unless you know the GPG CLI off by heart. See [1] for an example. 

https://github.com/infinity0/l33tutils/blob/master/data/security/gpgen.sh

Batch mode would be much nicer.

>> 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 ;-)
> 

Seriously though, it is bad UX experience to go several steps without being able to correct yourself.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140920/b01ad069/attachment-0001.sig>