Annoying bug: gpg-agent+gnupg and cancelling in pinentry-* repops pinentry two times

Marc Mutz Marc.Mutz at uni-bielefeld.de
Fri Jan 17 00:00:02 CET 2003


Hi!

I think this is a pretty serious usability bug and people are starting 
to run into it already. Expect more and more complaints about his to 
come when KDE 3.1 ships in a few days with a CryptPlug enabled KMail. 
;-)

The story goes as follows:

(gpg-agent from newpg 0.94; GnuPG 1.2.1; pinentry 0.6.7)

The information that the user cancelled in pinentry which is still 
present here:
  gnupg/g10/passphrase.c:agent_get_passphrase (~ l.805)
<snip>
      else if (nread > 7 && !memcmp (pw, "ERR 111", 7)
               && (pw[7] == ' ' || pw[7] == '\n') )
        log_info (_("cancelled by user\n") );
      else
        {
          log_error (_("problem with the agent - disabling agent 
use\n"));
          opt.use_agent = 0;
        }
    }

 failure:
  m_free (atext);
  if ( fd != -1 )
    agent_close (fd);
  m_free (pw );
  free_public_key( pk );

  return NULL;
#endif /* Posix or W32 */
}

is not reported back to the caller of agent_get_passphrase (it just 
returns NULL, which the caller passphrase_to_dek converts to "" in 
l.1037). Thus STATUS_MISSING_PASSPHRASE is written in 
passphrase.c:1084:

    if( !pw || !*pw )
        write_status( STATUS_MISSING_PASSPHRASE );

and an empty passphrase is used to construct the DEK. That will fail to 
unlock the secret key, the user will be asked again and so on, for 
three rounds. This is really annoying!

What needs to be done?
1. return the information that the user cancelled pinentry from
   agent_get_passphrase to passphrase_to_dek
2. Extend the status-fd protocol to include a STATUS_CANCELLED
3. Make passphrase_to_dek write_status( STATUS_CANCELLED ) in the cancel 
case instead of STATUS_MISSING_PASSPHRASE and make it report that 
incident back to it's callers.
4. Make the callers of passphrase_to_dek honour the cancel information 
so they don't try two more times.
5. Make gpgme recognize the new status and properly return exisiting 
GPGME_Canceled or new GPGME_Externally_Canceled error codes.

The _very_ urgent part is deciding whether you want to use the existing 
GPGME_Canceled error code for this or if you want to use a new one and 
if so, what value it will have. I can then patch KMail to handle that 
case gracefully and apply it to KDE_3_1_BRANCH. It's probably too late 
for 3.1.0, but then distributors will use the KDE_3_1_BRANCH, not the 
release anyway.

I can also handle both GPGME_Canceled and (GpgmeError)24 as meaning 
"user cancelled", but then we get a problem if you decide to use the 
existing _Canceled and later assign 24 to something else...

Marc

-- 
Ein Grundrecht auf Sicherheit steht bewusst nicht in der Verfassung.
  -- Sabine Leutheusser-Schnarrenberger (ehem. Bundesjustizministerin)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : /pipermail/attachments/20030117/6430996e/attachment.bin


More information about the Gnupg-devel mailing list