How to send GnuPG signed mail to linux-kernel and maintainers?

How to send GnuPG signed mail to linux-kernel and maintainers?

[Luca Barbieri]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

Until now, I have sent mail to linux-kernel using an unmodified version
of Ximian Evolution with PGP sign turned on. 

However, I've noticed that this causes the message to contain some
escape codes that, after reading a few RFCs and the source code, turn
out to be caused by the fact that Evolution, in compliance with RFC2015,
sends PGP-signed bodies as quoted-printable unless they are already
tagged as base64. 

The rationale is that quoted-printable avoids any modification by
gateways that would obviously cause the signature to be invalid. 
However, both the cs.helsinki.fi archive and Linus' scripts (he is
quoted in the L-K FAQ saying that he only wants unmangled text/plain) do
not properly support MIME transfer encodings. 
Furthermore, if a gateway modifies a message, patches should also be
adversely affected, so this shouldn't be a problem.

Thus, among the possible solutions, the best one (and the one I'm
currently using, by patching Evolution) appears to be violating the RFC
and sending as 7-bit rather than as quoted-printable, risking
invalidation of the signatures by gateway modifications.

Not using digital signatures is obviously not an option since there is
no way to prove that a message was not authentic (if it contains a
trojan patch, for example). 

Is this solution the best/recommended one? 
Shouldn't this be added to the FAQ? 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: How to send GnuPG signed mail to linux-kernel and maintainers?

[Dave Jones]

On Sun, May 26, 2002 at 02:29:07PM +0200, Luca Barbieri wrote:
 > Not using digital signatures is obviously not an option since there is
 > no way to prove that a message was not authentic (if it contains a
 > trojan patch, for example). 

Just because a patch has been signed does not mean it somehow manages
to bypass peer review.

If the patch is correct, it gets applied. If it's not obviously correct,
it gets reviewed by someone more familiar with the code.

Some people have a hard enough time getting patches they believe are
legitimate features/fixes past Al Viro, Dave Miller and the likes.
The chances of a trojan patch getting past them is I would hope, extremely minimal.

    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: How to send GnuPG signed mail to linux-kernel and maintainers?

[Luca Barbieri]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

On Sun, 2002-05-26 at 14:50, Dave Jones wrote:
> On Sun, May 26, 2002 at 02:29:07PM +0200, Luca Barbieri wrote:
>  > Not using digital signatures is obviously not an option since there is
>  > no way to prove that a message was not authentic (if it contains a
>  > trojan patch, for example). 
> 
> Just because a patch has been signed does not mean it somehow manages
> to bypass peer review.
> 
> If the patch is correct, it gets applied. If it's not obviously correct,
> it gets reviewed by someone more familiar with the code.
> 
> Some people have a hard enough time getting patches they believe are
> legitimate features/fixes past Al Viro, Dave Miller and the likes.
> The chances of a trojan patch getting past them is I would hope, extremely minimal.

Signing a patch and getting it applied are completely separate issues.
OTOH, if Linus or anyone else has a policy of dropping all mail using
non-plaintext encodings, sending it using such an encoding is a sure way
of preventing its application.

What I was trying to say is that someone might post a trojan patch with
my name and after it gets rejected, I might get accused of trying to get
it applied. And if the forger somehow manages to get it applied the
damage to me is even greater.

Another problem that arises from unsigned messages and people not
verifying signed ones is that someone may send a message pretending that
it is from a legitimate maintainer of a patchset (including you) and
announce a new version of the patchset with a changed URL.
If the patchset maintainer doesn't immediately notice the problem,
several people might apply the patchset, trusting the maintainer, before
the forgery is exposed.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]