Re: Trailing whitespace and PGP/MIME

[Simon Josefsson <jas@extundo.com>]

Jesper Harder <harder@ifa.au.dk> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Jesper Harder <harder@ifa.au.dk> writes:
>>
>>> It'll fix pgp/mime, but it will also force QP for inline pgp if you
>>> use a signature -- which for a lot of people means _always_ -- thus
>>> more or less reverting the intention of your previous change.
>>
>> Ah.  Hm.  Er.  So what IS the right thing?  The MUST above is for
>> PGP/MIME, yes, but the _reason_ the MUST is there in the document is
>> about as valid for plain PGP as it is for PGP/MIME, I think, arguing
>> that the obvious approach is the right.
>
> I'm not sure all the reasons are valid for cleartext signatures.
>
> In RFC 2440 textmode is used for cleartext signatures.  PGP/MIME
> allows you to use either a textmode or a binary mode detached
> signature.
>
> I think that's why they need the extra restrictions.  Trailing SPC
> doesn't matter if you're only using textmode, because it's ignored
> when computing the signature.

Yes.  I believe pre-OpenPGP implementations did not ignore trailing
SPC, even in "textmode", though.  I think that's one of the reason
PGP/MIME require that they shouldn't be present -- so that pre-OpenPGP
tools compute the same hash.

One alternative would be for Gnus to require an OpenPGP
implementation.  This would solve some other problems as well, such as
QP of dash escaped text for RFC 1991 compatibility.  But it would mean
dropping support for PGP 2.x, and perhaps some of 5.x/6.x/etc too.  I
don't particularly care about those, but perhaps some do.  Opinions?

> |   6.3.115 pgp_create_traditional

Interesting, thanks for the reference.

>> There are many things on this list now, e.g., non-ASCII,
>
> Yup, I agree that inline signatures are unsuitable for non-ASCII.

However, raw 8-bit with plain PGP can work well.

>> trailing unencoded SPC,
>
> I don't think that's a problem.

See above, it might be.

>> data that look dash escaped.
>
> But gpg seems to handle dash-escapes just fine:
>
> - -

See above, RFC 1991 implementation does not understand how to revert
dash escaped text.  That's why QP encoding could be used for text that
might be dash escaped.  But that doesn't work if QP isn't already used
for other reasons, such as non-ASCII -- reverting to QP just for this
seems excessive.

> Also, the "PGP sign part" and "PGP encrypt part" commands should
> probably be removed, since Gnus itself isn't even able to handle the
> result.

Yes...  ideally they should be fixed to generate inline PGP within
MIME parts, which is what most Outlook PGP users appear to generate
(and parse).