Hmm that came over a bit sensationalistically, let me clarify the
bounds of the problem as I understand them.
> Mailcrypt-3.5 introduced pgp5 and gnuPG support. But they also
> changed the variable name. So if kept your existing .emacs file, they
> would silently ignore your user-id selection, and use the default
> behavior which is to search for the key with user-id containin as a
> substring your unix log in name.
>
> As a result you could for example use mailcrypt's remailer features,
> and upgrade to mailcrypt-3.5.5 from mailcrypt-3.4 and end up exposing
> the first identity lexically on your secret keyring.
So actually mailcrypt-3.5.x, as mailcrypt-3.4.x, does display the key
you are being asked for a passphrase of in the mini-buffer; however
I've never found what is displayed in that buffer that reliable, and
the minibuffer is rather small so it can end up truncating what you
really need to see.
Anyway, the way I found out about the bug, was by sending someone who
checks signatures (thanks Ben Laurie) a signed message. I'm not sure
how many other signatures I've signed with some misc. test keys by
accident, and the recipients have simply not bothered to check the
sigs. It's even possible as an occasional remailer user that I may
have signed something sent via remailers that actually identifies me.
So empirically it can be a security problem, because basically it
caught me, and I am generally careful with PGP.
An additional nuance is that unless the key you intended to use and
the key it ended up using have the same passphrase, or the key you
ended up using has no passphrase, pgp will fail to decrypt the private
key.
Adam
