Why 2.1 is delayed for so long

[Werner Koch]

On Sat, 20 Sep 2014 04:44, infinity0 at pwned.gg said:

> * --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?

The same way you have always done it with gpgsm: Backup
~/.gnupg/private-keys-v1.d/ 

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

Yes, you need to do that.  This is actually how I run my tests.  

In the test home directory I do

  GNUPGHOME=$(pwd) agent/gpg-agent --daemon ~/bin/gnupg-setup-tests

with the script being:

--8<---------------cut here---------------start------------->8---
#!/bin/sh

cat >setup-tests.ini <<'EOF'
PS1="$(echo "$PS1" | sed 's,\\\$ $,(GnuPGTest)\\\$ ,')"
EOF
exec bash --init-file setup-tests.ini
--8<---------------cut here---------------end--------------->8---

The reason for having the secret material all in one place is the
standard crypto practice of placing your eggs/keys all into one basket
and guard them closely.  You may even symlink the private-key-v1.d to share
them between different (test) installations.

> * when auto-generating a key, I'm now prompted to input a passphrase
> for every single subkey. For newly-generated keys, the message is

Are you sure that you use the latest agent?  Does 

  gpg-connect-agent 'getinfo version' /bye

show the right version number (at least 2.1.0-beta834)>

> "Please enter the passphrase for your new key", you should say "Please
> enter the passphrase for your new ECC key, <UID>, expires

Good suggestion.  Hoever, I would keep the algorithm out.

> * 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])

I don't understand what you mean.  --batch has always been docuemnted as
not requiring any user input at runtime.

> * 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!)

Doing it the inteactive way is more informative and avoids i18n
(translation) problems.  At some point the prompt will simply be removed.

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

Maybe.  But most people use a GUI frontend anyway.  Did you know that you
could enter a '?' on response to all prompt.  You will see a help text
which can be locally be changed to suite an organizations needs.

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

Too much details - not a good idea.

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

Thus there is the "(default)" marker which is what newbies should do.

> would better be named:
>
>    (7) DSA (set your own signing capabilities)
>   (11) ECC (set your own signing capabilities)

I prefer generic strings.  And well, there is just one signing
capability, the others are called authentication, encryption, and
certification.

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

Me too, but there are a couple of problems and encryption is not as
important as signing (i.e. certification).  Adding an encryption subkey
can be done at any time. In the meantime you can collect key signatures
if you like.


Shalom-Salam,

   Werner


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