Adding support for fetching GPG key using WKD protocol
invalid at pizzashack.org
Fri Jul 6 16:59:07 UTC 2018
I'm not strongly opposed to this feature, but I am opposed to it
nonetheless, on much the same grounds as I am opposed to the "umask"
feature (which is a misnomer, but it's how people think of that) for
attachments. Convenience and security, unfortunately, are often
enemies, and I think this is another case of that. If this feature is
included, it is certain that many users will enable it for the sake of
convenience, but many of those users will not have a sufficiently
sophisticated understanding of the security risks associated with that
action, and will thus be incapable of making a truly informed
decision about whether those risks are worth the added convenience.
On that basis I think Mutt should force the user to explicitly decide
that they want to fetch a key, by doing so through the gnupg
Another way to look at this: Mutt likes to relegate tasks to an
application which is designated for that task. In this case, gnupg
(or whatever) is the application relegated to managing PGP keys. As
such the user should configure THAT application, to the extent
possible, to do what they want with keys, and Mutt should ignore the
As a side note, I think automatic key retrieval of any sort largely
defeats the purpose of encryption. You have no idea if the key you've
downloaded actually belongs to the person you think it should belong
to, excepting the case where the key is just a refresh of a key you've
already manually verified (i.e. key is signed by a key you already
have verified, belonging to the same person). There are sometimes
other reasons, or other means by which to trust such keys (e.g. the
web of trust); but in the general case it is simply stupid to do so
without manually verifying the key and its owner's identity yourself.
You can consider that an additional argument to not support the
feature if you like.
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
On Wed, Jul 04, 2018 at 11:27:23PM +0200, Wiktor Kwapisiewicz wrote:
> Hello mutt-dev,
> I would like to extend mutt to add fetching GPG keys over Web Key
> Directory protocol.
> (I've previously created an issue on gitlab  but I'll summarize
> the thing here for the broader audience).
> Web Key Directory is a new scheme for GPG key discovery. It converts
> the e-mail address to HTTPS URL and fetches the key from there. It
> is already supported by some e-mail clients (EnigMail, GpgOL).
> For example kernel.org has it enabled and Linus' key is at: https://kernel.org/.well-known/openpgpkey/hu/pf113mfnx1f3eb1yiwhsipa91xfc7o4x
> As GnuPG 2 has it enabled by default "gpg --locate-key
> torvalds at kernel.org" will fetch that key.
> I've been exploring mutt's source code and the change would mostly
> be enabling external lookup for keys that are not locally present
>  when encryption is explicitly turned on (gpgme backend).
> That raises some privacy issues, the same was discussed on
> gnupg-devel ML  (gpg by default will fetch the key via WKD when
> encrypting to a recipient but will *not* fetch the key when
> verifying signatures).
> The question is how to do it well. Maybe ask the user if they want
> to search for the key using WKD if it's not locally present?
> An option would be the first choice but I worry about it not being
> used at all (as people rarely enable non-standard features ).
> Thank you for your consideration!
> Kind regards,
> : https://gitlab.com/muttmua/mutt/issues/55
> : gpgme_set_keylist_mode(ctx,
> GPGME_KEYLIST_MODE_LOCAL|GPGME_KEYLIST_MODE_EXTERN); in
> : https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033021.html
> : https://gitlab.com/muttmua/mutt/issues/3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Mutt-dev