=app-misc/mime-types-9 added the "asc" extension to the "application/pgp-encrypted" MIME-type. As many people store ASCII armored GnuPG output into files with "asc" extension, they since have their GnuPG output files identified as "application/pgp-encrypted". However, "application/pgp-encrypted"'s definition (RFC 3156) is counter-intuitive. "application/pgp-encrypted" is not for encrypted content. "application/pgp-encrypted" is only for control information [1]: [...],the first with content type "application/pgp-encrypted". This body contains the control information. A message complying with this standard MUST contain a "Version: 1" field in this body. The body of "application/pgp-encrypted" literally has to hold the string "Version: 1" and nothing else. This conflicts with =app-misc/mime-types-9 applying "application/pgp-encrypted" to GnuPG output files ending in "asc". Can we stop associating "asc" with "application/pgp-encrypted"? (Just as Debian [2], Fedora [3], or RFC [4]) In fact ... due to its rigorous, counter-intuitive definition in RFC 3156, the type "application/pgp-encrypted" looks rather pointless and misleading in app-misc/mime-types altogether. Would it be better to get rid of "application/pgp-encrypted" altogether? Because who stores "Version: 1" in a file (which would be the only valid content for "application/pgp-encrypted")? ---------------------------------------------------- Steps to expose issues with the improperly applied "application/pgp-encrypted": * In GnuPG, export a public key to the file "foo.asc" Like: gpg -a --export $YOUR_KEY_ID > foo.asc * In mutt, compose an email and attach above "foo.asc" Actual behaviour: * Mutt shows the attachment with MIME-Type "application/pgp-encrypted". But since the content of foo.asc is not "Version: 1", this is an invalid email. Upon sending the email, mutt enforces the RFC's definition of "application/pgp-encrypted" and overrules the attachment's content by making it "Version: 1". The email recipient receives an "application/pgp-encrypted" attachment with content "Version: 1" (i.e.: the only possible valid "application/pgp-encrypted" content) instead of the key stored in "foo.asc". Expected behaviour: * Mutt shows the attachment with MIME-Type * "application/pgp-keys", or * "application/pgp-signature", or * "text/plain", or * some other MIME-Type that is different from "application/pgp-encrypted". Thereby, the attachment's content does not get overruled upon sending, and the mail recipients receive the key in foo.asc [1] From RFC 3156 “MIME Security with OpenPGP” http://tools.ietf.org/rfcmarkup?doc=3156#page-3 [2] Fedora does not seem to associate asc ending with application/pgp-*: https://git.fedorahosted.org/cgit/mailcap.git/tree/mime.types#n207 [3] Neither does Debian: http://anonscm.debian.org/cgit/collab-maint/mime-support.git/tree/mime.types?id=bdfd714b5ecc45195d3b15f22050440f7e00d5c6#n98 [4] The RFC does not associate any file extension: http://tools.ietf.org/html/rfc3156#page-9
Resolved by app-misc/mime-types-2.1.53. See bug 762958 for further information.
Regarding the question of whether the type should be removed altogether, I'd suggest raising it with the maintainer of https://pagure.io/mailcap, as this is now Gentoo's upstream.
