Menu
▾
▴
#1 Incorrect PGP/MIME handling
Incoming PGP/MIME messages are not properly handled,
resulting in
extra headers like
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
at the top of every resent message. Furthermore,
Content-type is
not thought to be correctly propogated, meaning that
messages
with attachments are likely to come out a bloody mess.
Logged In: YES
user_id=672160
from zephyr-land:
Okay, walking through the cases, extract should do exactly
what it
does now (ignore MIME goop and find the first -----BEGIN PGP
MESSAGE-----) except that it should pass a flag saying
whether the
message had a content-type header indicating pgp/mime goodness.
if the flag is clear, decrypt does what it does now. if the
flag is
set, decrypt does what it does now, then grabs the first foo
lines,
terminated a blank line, as mime section headers and holds on to
them. (these will be content-type, content-transfer-encoding,
content-disposition, content-id, content-description)
process does what it does now.
encrypt:
* for mime recipients, prepend the mime section headers and
a blank
line before encryption, and wrap the encrypted text in a
boilerplate
mime body, and set content-type on the message to
multipart/encrypted,
protocol application/pgp-encrypted. but if we don't have
section
headers, that means the incoming message wasn't mime, so i
guess we
make the encrypted part be content-type: text/plain.
* for non-mime recipients, we find ourselves asked to render
a mime
message into plaintext. "oops." this is not the way mime
is supposed
to work; i suppose this is actually the problem pgp/mime
is intended
to solve. we could just dump the body without the headers, or
attempt to convert it to quoted-printable if it is
base64'd for some
reason (though that probably indicates binary data), or
foolishly
attempt to convert quoted-printable to our 'personal favorite'
concept of 7bit. that's assuming the content-type wasn't a
multipart
type. in the case of multipart types, we could either
dump the
attachments, keepign the first one arbitrarily, or dump
the raw mime
data including the section headers for the user to stare
blankly at,
or insert comments in brackets telling the user what kind
of tools
(eg, base64 programs) she might use to recover the
attachments.
Logged In: YES
user_id=672160
To make this work in the case of signed and encrypted messages
implemented as nested multiparts, extract needs to strip off
any signatures.
Unfortunately, that involves invoking gpg, since the body
(apparently?) could
be armored. Maybe I'm confused on that last bit, though.
"That can come next."
Logged In: YES
user_id=672160
I have checked in preliminary support based on the strategy
I described
earlier. This should handle nearly all cases. Support for
signatures as
armored, nested multiparts will have to come later, though.