Why 2.1 is delayed for so long

[Werner Koch]

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.

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


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

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

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


Salam-Shalom,

   Werner

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