Re: [RFD] Explicitly documenting patch submission

Linus Torvalds
2004-05-23T15:53:57Z

On Sun, 23 May 2004, Arjan van de Ven wrote:
>
> Can we make this somewhat less cumbersome even by say, allowing
> developers to file a gpg key and sign a certificate saying "all patches
> that I sign with that key are hereby under this regime". I know you hate
> it but the FSF copyright assignment stuff at least has such "do it once
> for forever" mechanism making the pain optionally only once.

One reason that I'd prefer not to is simply the question of "who maintains
the certificates?"

I certainly don't want to maintain any stateful paperwork with lots of
people. This is why I personally would prefer it all to be totally
state-less.

Also, there is a _fundamental_ problem with signing a patch in a global
setting: the patches _do_ get modified as they move through the system
(maybe just bug-fixes, maybe addign a missing piece, maybe removing a
controversial part). So the signature ends up being valid only on your
part of the communication, and then after that it needs something else.

And what I do _not_ want to see is a system where if somebody makes a
trivial change, it then has to go back to you to be re-signed. That just
would be horrible.

With those (pretty basic) caveats in mind, I don't see any fundamental
problem in a PGP key approach, if it's a "local" thing between developers.
In fact, I think PGP-signed patches are something we may want to look at
from a "trust the email" standpoint, but I think it should be a _local_
trust. And part of that "local" trust might be a private agreement between
ddevelopers that "it's ok to add the sign-off line for Arjan when the
patch has come with that PGP signature" when the patch is passed on.

So to me, the sign-off procedure is really about documenting the path, and
if a PGP key is there in certain parts of the path, then that would be a
good thing, but I think it's a separate thing from what I'm looking for.

Linus