Why 2.1 is delayed for so long

[Ximin Luo]

On 19/09/14 13:30, Ximin Luo wrote:
> On 19/09/14 09:49, Werner Koch wrote:
>> On Thu, 18 Sep 2014 02:25, djhaskin987 at gmail.com said:
>>
>>> also seen Werner say on this mailing list that he has used 2.1 "for
>>> years now". I wonder if there is a measure by which the four-year-old
>>> version shall be considered stable. If so, what is it? If not, or if
>>
>> Never change a running system (i.e. 1.4).  I am glad to see that after
>> 11 years 2.0 is now going mainstream.
>>
>> I assume that 2.1 will be be adopted faster because it has improvements
>> which are fashionable now; in particular ECC.  However, ECC is also one
>> of the problems why 2.1 is delayed.  The plan is to implement the new
>> non-TLA created ECC curves (Curve255519).  Last fall it looked that the
>> IETF would fast adopt they as standards but they keep on debating.  Thus
>> the likely outcome is that 2.1 will be released without an official IETF
>> standard for the new curves.
>>
>> I did a new beta yesterday but my experience with beta versions is that
>> they are not widely used or problems/success are not reported.  To move
>> forward we might have to jump into cold water and release 2.1 without
>> having many test results.  And I need to set aside enough time to
>> quickly work on reported problems after 2.1.0.  Thus all other
>> construction areas should be cleaned up before.
>>
> 
> FWIW I would be happy to help test, if someone makes a Debian package for gnupg 2.1. I might do that myself this weekend. Let me know if there's any significant installation differences between 2.0 and 2.1.
> 
> Is the data format for EdDSA keys now final?
> 

First impressions testing 2.1:

* --secret-keyring has no effect. How do I back up my secret keyring? It seems secrets are now controlled by the agent? How do I back this stuff up?
** What if I (or a program I'm using) want to separate my secrets into separate locations? I need to start a new gpg-agent for each homedir? This would be quite awkward to do.

* when auto-generating a key, I'm now prompted to input a passphrase for every single subkey. For newly-generated keys, the message is generic and has no context, so 7 pop ups in a row is very confusing. Could some sort of context be added? Instead of saying "Please enter the passphrase for your new key", you should say "Please enter the passphrase for your new ECC key, <UID>, expires XYZ". Similar thing for exporting keys, and I'm sure there are other uses.

* no more documentation describing batch mode? (I hope it is much improved; last time I checked batch mode it was very limited and not fit for purpose; I had to script up the normal CLI instead. [1])

* Instead of having to confirm yet again "Use this curve anyway? (y/N) y" I would just put it in the key selector display:

Please select which elliptic curve you want:
   (1) Curve 25519 (not yet part of OpenPGP standard!)

* I've always thought the key creation descriptions were counter-intuitive. I guess they were intended to be "simple for newbies", but I don't think this goal is achieved, rather it makes it worse. The current descriptions present to the user a mental model that is completely different from what is actually happening. Instead of the current:

   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (9) ECC

they should be named:

   (1) RSA (for sign+certify) and RSA subkey (for encryption)
   (2) DSA (for sign+certify) and Elgamal subkey (for encryption)
   (9) ECC (for sign+certify) and ECC subkey (for encryption)

I think this is much clearer. Even for newbies, it at least hints to what is going on, which means they can build up a mental model.

Also, these two:

   (7) DSA (set your own capabilities)
  (11) ECC (set your own capabilities)

would better be named:

   (7) DSA (set your own signing capabilities)
  (11) ECC (set your own signing capabilities)

Also, +1 for getting Curve25519 encryption working...

X

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

-- 
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/689aee91/attachment.sig>