Annoying bug: gpg-agent+gnupg and cancelling in pinentry-* repops
pinentry two times
Marc.Mutz at uni-bielefeld.de
Fri Jan 17 00:00:02 CET 2003
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
gnupg/g10/passphrase.c:agent_get_passphrase (~ l.805)
else if (nread > 7 && !memcmp (pw, "ERR 111", 7)
&& (pw == ' ' || pw == '\n') )
log_info (_("cancelled by user\n") );
log_error (_("problem with the agent - disabling agent
opt.use_agent = 0;
if ( fd != -1 )
m_free (pw );
free_public_key( pk );
#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
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
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...
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
Size: 189 bytes
Url : /pipermail/attachments/20030117/6430996e/attachment.bin
More information about the Gnupg-devel