Why 2.1 is delayed for so long

[Ximin Luo]

On 22/09/14 13:26, Werner Koch wrote:
> On Sat, 20 Sep 2014 16:11, infinity0 at pwned.gg said:
> 
>> 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.
> 
> That is why I suggested to unset GPG_AGENT_INFO in the bashrc.  I need
> to research whether we can completely do without GPG_AGENT_INFO.  IT is
> only used in case a non-standard socket is used.  For what I know, this
> is required if the GNUPGHOME is mounted on file system which does not
> support sockets (i.e. remove file system or vfat).  An idea would be to
> stat the socket file and if is a real file, read the name of the to be
> used socket form that file.  Thus it must be created prior to starting
> gpg-agent and be considered a configuration file.  This would actually
> help to remove some code from GnuPG.  Implementation should be easy, most
> can be done in Libassuan.
> 

OK. This is a major issue I can see for GPG 2.1 as a user, I will keep an eye on it.

As for the upgrade behaviour that dkg and I had problems with: how about, when gpg 2.1 upgrades your homedir, it does a "getinfo" on the gpg-agent it connects to, and if it's actually a 2.0 gpg-agent then it kills it and starts a 2.1 one automatically?

>>>> 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.
> 
> The script should tell that the user.  If you think this is important,
> please add it as a feature request for 2.1 to the BTS.
> 

OK, I will file.

> 
>   [pinentry while signing]
>> 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.
> 
> Sorry, I don't understand.
> 
>> For GPG 2.1, key creation only says "Please enter the passphrase to
>> protect your new key".
> 
> 1.4 and 2.0 use very similar prompts.  We can't use the standard prompt
> because we do not know the keyid at that point.  Yes, we could ask after
> key creation but that has the problem that the prompt for the
> passphrase would show up only after minutes and the user needs to wait
> for it and not come back and the key has already been protected and
> saved.
> 

You don't know the keyid for the master key, but you know the UID and expiry date, and the fact it's a master key.

For subkeys, you know the master key it's associated with, and its UIDs. This would be useful information in the prompt as well. Come on, work with me here instead of just trying to find ways to knock down my suggestions. I am trying to help.

>> 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!
> 
> I assume that if there is a need for it, you have the time to implement
> a proper script to control gpg.  Sometimes new commands make sense, like
> the --quick-sign-key I implemented for something John Gilmore was
> hacking on.
> 
>> 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]
> 
> 
> No, no.  You should never do it this way.  That is not scripting the
> interface but feeding it with canned commands.  This will for sure
> break.  For example the original author of GPA did it this way and it
> broke with the next vesion of gpg.  It is entirely unreliable.  GnuPG
> has a machine oriented interface for a reason; you are ignoring it.
> 
> Here is an extract from mail-signed-keys which uses the machine
> interface as intended:
> 
>   gpg OTHEROPTIONS --check-sigs --with-colons 2>/dev/null \
>        | awk -F: -v signedby="$signedby" '
>   BEGIN	      { sendmail="/usr/lib/sendmail -oi -t " }
>   $1 == "pub"   { nextkid=$5; nextuid=$10
>   		if( uidcount > 0 ) { myflush() }
>   		kid=nextkid; uid=nextuid; next
>   	      }
>   $1 == "uid"   { uid=$10 ; next }
>   $1 == "sig" && $2 == "!" && $5 == signedby  { uids[uidcount++] = uid; next }
>   END	      {  if( uidcount > 0 ) { myflush() } }
>   '
> 
> Using --gen-key is more complicated, though.  You need to wait for
> "[GNUPG:] GET_LINE", switch on the following argument
> (e.g. "keygen.algo") and send appropriate answers.  If you not know the
> argument, just answer with a LF which takes the default.  You should see
> "GOT_IT" line next; if not something went wrong.  You can do that with
> awk or perl, or whatever you like.
> 

OK, it is good there is some sort of machine-scriptable interface in mind. Ideally though, one should not have to go to the complexity of writing a multi-round request-response protocol script, for a task where you already know all the input info at the start of the task - such as key generation. But sure, I get you have other things to do; I can have a go at writing a python script or that reads a descriptor like "batch mode" and interacts with GPG via GET_LINE to create a key. (I would just fix "batch mode", but I'm not good at C.) Would you be interested in having that as part of GPG, as a key generation script?

Are the parameters documented anywhere? For example, I see GET_LINE in DETAILS but no mention of the possible options it takes. Of course I can play with it, it is just more awkward and I'd have to guess the behaviour.

>> Seriously though, it is bad UX experience to go several steps without
>> being able to correct yourself.
> 
> Yeah well, but in the last 16 years that was not a real problem.
> Implementing such extras is easy but testing them takes lots of time.
> 

UX issues are typically not "problems" that people will bother reporting. Indeed I didn't bother, until I came to write about other more important things, and thought I'd lump it in. OK, I will file a bug for this and we'll see if it ever gets done.

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/20140923/afbaa3e0/attachment.sig>