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

[Marc Mutz]

--Boundary-02=_wEzJ+UTiD3NNkwJ
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

Hi!

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

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

 failure:
  m_free (atext);
  if ( fd !=3D -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=20
returns NULL, which the caller passphrase_to_dek converts to "" in=20
l.1037). Thus STATUS_MISSING_PASSPHRASE is written in=20
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=20
unlock the secret key, the user will be asked again and so on, for=20
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=20
case instead of STATUS_MISSING_PASSPHRASE and make it report that=20
incident back to it's callers.
4. Make the callers of passphrase_to_dek honour the cancel information=20
so they don't try two more times.
5. Make gpgme recognize the new status and properly return exisiting=20
GPGME_Canceled or new GPGME_Externally_Canceled error codes.

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

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

Marc

=2D-=20
Ein Grundrecht auf Sicherheit steht bewusst nicht in der Verfassung.
  -- Sabine Leutheusser-Schnarrenberger (ehem. Bundesjustizministerin)

--Boundary-02=_wEzJ+UTiD3NNkwJ
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+JzEw3oWD+L2/6DgRAmDIAKD9RIbLGToqUOq7rVVhe8zc3CWYJwCfXesm
KiavRyHw6i+khQF27jcO5Cg=
=babA
-----END PGP SIGNATURE-----

--Boundary-02=_wEzJ+UTiD3NNkwJ--