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 interface.
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 problem. 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 [0] 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 > torva...@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 > [1] when encryption is explicitly turned on (gpgme backend). > > That raises some privacy issues, the same was discussed on > gnupg-devel ML [2] (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 [3]). > > Thank you for your consideration! > > Kind regards, > Wiktor > > [0]: https://gitlab.com/muttmua/mutt/issues/55 > > [1]: gpgme_set_keylist_mode(ctx, > GPGME_KEYLIST_MODE_LOCAL|GPGME_KEYLIST_MODE_EXTERN); in > crypto-gpgme.c#get_candidates. > > [2]: https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033021.html > > [3]: https://gitlab.com/muttmua/mutt/issues/3 > > -- > https://metacode.biz/@wiktor
pgp1zSHNO7_rx.pgp
Description: PGP signature
