Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 534658 - app-misc/mime-types improperly applies "application/pgp-encrypted" to *.asc files
Summary: app-misc/mime-types improperly applies "application/pgp-encrypted" to *.asc f...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Dirkjan Ochtman
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-04 16:00 UTC by c.mittermayer
Modified: 2015-01-04 21:55 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description c.mittermayer 2015-01-04 16:00:06 UTC
=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