737523 - PGP encrypted messages should be sent multipart/encrypted

Status: NEW

(bugzilla.mozilla.org :: Extensions, enhancement)

Description

[Mike Hommey [:glandium]]

This is the kind of headers/content that mutt generates when it PGP encrypts:

Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
	boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline
--vkogqOf2sHV7VnPd
Content-Type: application/pgp-encrypted
Content-Disposition: attachment

Version: 1

--vkogqOf2sHV7VnPd
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="msg.asc"

-----BEGIN PGP MESSAGE-----
(...)
-----END PGP MESSAGE-----

--vkogqOf2sHV7VnPd--


That makes it decrypt automatically.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A workaround for mutt users is to add the following line to ~/.muttrc :

message-hook '~s "\\(Secure bug updated\\)"' 'exec check-traditional-pgp'

Comment 2

[:glob ✱]

it looks like some older MUAs don't support MIME+PGP (eg. outlook express); given there's a work around (thanks dbaron!) i'm not sure we should make this change.

Comment 3

[Gervase Markham [:gerv]]

Who is using Outlook Express to read secure bugmail? OE doesn't support PGP at all out of the box, does it? So is it some OE extension which doesn't support this?

Is it only Mutt which has this problem? 

It does seem to me that inline encryption is a bit of a hack, and multipart is the "proper" way to do it...

Gerv

Comment 4

[:glob ✱]

(In reply to Gervase Markham [:gerv] from comment #3)
> Who is using Outlook Express to read secure bugmail?

on bmo, hopefully no one!
i can't answer for anyone else using the securemail extension.

> OE doesn't support PGP at all out of the box, does it? So is it some OE extension
> which doesn't support this?

good question and one i don't know the answer to; i gathered this info from http://wiki.mutt.org/?MuttFaq/Encryption

> Is it only Mutt which has this problem? 

unknown, however it's the only one that's been reported.

> It does seem to me that inline encryption is a bit of a hack, and multipart
> is the "proper" way to do it...

it isn't a hack, it's just an older style of encryption.


i'm curious about the amount of change required -- can someone please send me a pgp encrypted mail from mutt, my public key is in http://glob.pastebin.mozilla.org/1531981

Comment 5

[Mike Hommey [:glandium]]

> i'm curious about the amount of change required -- can someone please send me
> a pgp encrypted mail from mutt

Comment 0 is just that.

Comment 6

[:glob ✱]

(In reply to Mike Hommey [:glandium] from comment #5)
> > i'm curious about the amount of change required -- can someone please send me
> > a pgp encrypted mail from mutt
> 
> Comment 0 is just that.

comment 0 is highly edited; the blank line after the main headers appears to be removed, but i'm not sure.  i figure it is quicker to ask for a complete message than ask for clarification.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Byron Jones ‹:glob› from comment #4)
> i'm curious about the amount of change required -- can someone please send
> me a pgp encrypted mail from mutt, my public key is in
> http://glob.pastebin.mozilla.org/1531981

Done.

Comment 8

[Jeff Walden [:Waldo]]

(In reply to Byron Jones ‹:glob› from comment #2)
> it looks like some older MUAs don't support MIME+PGP (eg. outlook express);
> given there's a work around (thanks dbaron!) i'm not sure we should make
> this change.

Not to be too glib, but dbaron's needs are, or at least should be, more important than those of hypothetical Outlook Express users -- even if there are, implausibly, many of them.  And PGP-secured bugmail (S/MIME seems the more likely thing for corps to deploy if they wanted this) seems like the sort of thing where people who sign up for it are unlikely to be using OE, regardless -- even, I suspect, among hypothesized other-securemail-users.

Comment 9

[:glob ✱]

Attachment: sample message

Comment 10

[:glob ✱]

we should include the url to the bug in the main body (from bug 738799).

Comment 11

[:glob ✱]

including non-encrypted content in a multipart/encrypted looks tricky.

we'd have to structure it as:

multipart/alternative
    multipart/encrypted
        application/pgp-encrypted
        application/octet-stream
    text/plain (including message to incompatible clients)

however compatibility with email clients (such as engimail) is unknown.


i've thrown together a simple testcase to get feedback on if this works -- http://drop.glob.com.au/737523/

if you have a pgp enabled email client, please hit that url and let me know the results.

Comment 12

[Gervase Markham [:gerv]]

That form's not working for me. I submitted "[e-mail]" and the contents of http://www.gerv.net/GervPGPKey.asc, and it just times out, eventually with a "connection reset.

Gerv

Comment 13

[Mike Hommey [:glandium]]

In mutt this is what happens:

Opening the mail gets me a pgp passphrase prompt. Whether I enter the passphrase or not, the message I see is:
"This is a PGP encrypted message.
Hopefully you don't see this message if you have PGP installed!"

To see the encrypted message, I need to manually view-attachments, and then I can see the decrypted message by selecting the multipart/encrypted part.

Comment 14

[:glob ✱]

(In reply to Gervase Markham [:gerv] from comment #12)
> That form's not working for me. I submitted "[e-mail]" and the contents
> of http://www.gerv.net/GervPGPKey.asc, and it just times out, eventually
> with a "connection reset.

ah, i got bit by https://rt.cpan.org/Public/Bug/Display.html?id=68018
i've patched my server, shouldn't hang now.

(In reply to Mike Hommey [:glandium] from comment #13)
> In mutt this is what happens:
> 
> Opening the mail gets me a pgp passphrase prompt. Whether I enter the
> passphrase or not, the message I see is:
> "This is a PGP encrypted message.
> Hopefully you don't see this message if you have PGP installed!"
> 
> To see the encrypted message, I need to manually view-attachments, and then
> I can see the decrypted message by selecting the multipart/encrypted part.

thanks mike.  looks like we can't have our cake and eat it too :(


if we leave the message construction as is, we can insert a link to bmo in the body for people who don't or can't use pgp, and people running mutt can use the check-traditional-pgp function for automatic decryption.

if we switch to multipart/encrypted documents, it looks like we won't be able to insert the bug url in a way that satisfies the request on this bug.


given the amount of people using webmail clients, as well as all the security group members who don't have the group's private key, inserting the bug url is probably more important than addressing the mutt issue.

Comment 15

[David Lawrence [:dkl]]

Worked acceptably well for me Thunderbird/Enigmail and decrypted the encrypted portion automatically for me and displayed it in the top of the message. It also showed the text/plain portion inline below it which was an added plus.

dkl

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The revised workaround given recent changes is:

message-hook '~s "\\(Secure bug updated\\)"' 'exec check-traditional-pgp'
message-hook '~s "\\(Secure bug [0-9]+ updated\\)"' 'exec check-traditional-pgp'

Comment 17

[Michał Górny]

(In reply to Gervase Markham [:gerv] from comment #3)
> Is it only Mutt which has this problem?

Claws-mail has the same problem.

(In reply to Byron Jones ‹:glob› from comment #11)
> i've thrown together a simple testcase to get feedback on if this works --
> http://drop.glob.com.au/737523/
> 
> if you have a pgp enabled email client, please hit that url and let me know
> the results.

As expected, claws-mail displays this as a secure mail, asks for password and displays the encrypted content. However, the unicode characters in body seem to be mis-interpreted (the subject looks fine); I guess the content headers miss charset.

--------

Another problem with the current form is that while the body is encrypted, the X-Bugzilla-... headers show almost every information about the change unencrypted...

Last of it, if the bug number is public I suggest that the fallback message contained URL to it. This will provide a quick work-around for users who aren't able to decrypt the message ATM.

Comment 19

[Quanah Gibson-Mount]

I do *not* use mutt, and this failure to properly set the content type for encrypted messages makes them unreadable to me.  Please fix this.

Comment 20

[Gervase Markham [:gerv]]

Quanah: what MUA _are_ you using? Also, this bug is about message structure, not the content type header. You will need to provide more details, perhaps in a separate bug unless you are certain it's the same issue as this one.

Gerv

Comment 21

[Quanah Gibson-Mount]

(In reply to Gervase Markham [:gerv] from comment #20)
> Quanah: what MUA _are_ you using? Also, this bug is about message structure,
> not the content type header. You will need to provide more details, perhaps
> in a separate bug unless you are certain it's the same issue as this one.

I use Mulberry.

In any case, I did file a separate bug.  It was marked a duplicate of this one.  I've reopened my original report.

--Quanah

Comment 22

[Gervase Markham [:gerv]]

Quanah: Reading your original bug, it seems like the same thing to me. (Apologies for any confusion.)

Are you saying that Mulberry does not support the inline PGP style?

Gerv

Comment 23

[Quanah Gibson-Mount]

Correct.  It expects a valid content type to indicate that it is a PGP encrypted message

Comment 25

[Quanah Gibson-Mount]

http://tools.ietf.org/html/rfc3156

Comment 26

[naehring]

Any updates here? We're facing the problem with several users running on outlook with pgp-plugin. Thunderbird users don't have that problem, the inline works.

Comment 27

[Gervase Markham [:gerv]]

glob: it's not clear what the decision is here. Does your comment 14 suggest we should go ahead and change SecureMail to send mails structured as in comment 11?

Or is an option (shock! horror!) the only way to fix this?

Gerv

Comment 28

[:glob ✱]

(In reply to Gervase Markham [:gerv] from comment #27)
> glob: it's not clear what the decision is here. Does your comment 14 suggest
> we should go ahead and change SecureMail to send mails structured as in
> comment 11?

no, it says the opposite.  the multipart/alternative structure wasn't compatible with mutt, making it a non-option.

note- if we switch from traditional-pgp to multipart/encrypted then we'd be unable to insert any plaintext alternative content in the email.


the encapsulation options are:

1. convert pgp to multipart/encrypted
   - should help clients that don't support traditional pgp encapsulation
   - no ability to add any plaintext content (eg. bug 746812 will be impossible to fix)
2. continue to use traditional pgp
   - known to cause issues with some clients
   - has the ability to add plaintext content along side the payload

i'm not sure there's a clear winner here.

another option which may work is:

3. add information about the bug/change to the *you don't have a key set* body
   - and change pgp encapsulation to multipart/encryption
   - provides more information to users who do not set a public key
   - do not provide any information which isn't already available in the x-headers
   - include a link to the bug so they can visit the bug to get the details
   - compatible with all email clients :) not compatible with all workflows

Comment 29

[Gervase Markham [:gerv]]

(In reply to Byron Jones ‹:glob› (unavailable until jan 4th) from comment #28)
> no, it says the opposite.  the multipart/alternative structure wasn't
> compatible with mutt, making it a non-option.

http://www.mutt.org/doc/manual/manual-5.html#ss5.5 suggests that mutt's behaviour is configurable to a degree here. Is there a mutt user CCed on this bug who would be willing to explore tweaking these options to see if we can get a working config?

glob: can you revive http://drop.glob.com.au/737523/ so that person can generate themselves a message?

> note- if we switch from traditional-pgp to multipart/encrypted then we'd be
> unable to insert any plaintext alternative content in the email.

Yes, that seems suboptimal, given the bugs filed on increasing the data in the plain text part.

> 2. continue to use traditional pgp
>    - known to cause issues with some clients

Is this mutt again, but there is a workaround? Or do you mean Outlook Express? Or something else?

> 3. add information about the bug/change to the *you don't have a key set*
> body

So the idea would be that people with MUAs who don't support multipart/encrypted would just not set a key?

Gerv

Comment 30

[:glob ✱]

(In reply to Gervase Markham [:gerv] from comment #29)
> Is there a mutt user CCed on this bug who would be willing to explore tweaking
> these options to see if we can get a working config?

we already have that -- comment 16 (and earlier comment 1).

> glob: can you revive http://drop.glob.com.au/737523/ so that person can
> generate themselves a message?

sorry, that's long gone and i didn't remember what it did.

> > 2. continue to use traditional pgp
> >    - known to cause issues with some clients

> Is this mutt again, but there is a workaround? Or do you mean Outlook Express? Or something else?

comment 21 points to one other client that has issues.
OE has issues with multipart/encrypted not traditional encapsulation.

> > 3. add information about the bug/change to the *you don't have a key set*
> > body
> 
> So the idea would be that people with MUAs who don't support
> multipart/encrypted would just not set a key?

yes -- there's no point setting a key if your email client can't decrypt the payload.

Comment 31

[Gervase Markham [:gerv]]

We have now discovered that we can add some plain-text content to encrypted emails, for people who can't or haven't decrypted them, using comments; see bug 1190476.

So should we do glob's option 3?

Gerv

Comment 32

[:glob ✱]

(In reply to Gervase Markham [:gerv] from comment #31)
> We have now discovered that we can add some plain-text content to encrypted
> emails, for people who can't or haven't decrypted them, using comments; see
> bug 1190476.

the comment field you're referring to is very limited, and i think we should limit its use to just the bug url.

> So should we do glob's option 3?

#3 is for the *you don't have a key set* body.  the changes in bug 1190476 are for encrypted payload.