Re: PGP fingerprints in CREDITS file?

Michael K. Johnson (johnsonm@nigel.vnet.net)
Tue, 14 May 1996 08:48:08 -0400


"Theodore Y. Ts'o" writes:
>Reminder.... if people are sending in patches, *especially* patches
>containing their PGP key fingerprint, it would be useful if in fact
>Linus knew that the message containing the PGP Key fingerprint isn't
>going to be forged. :-)

Last I heard, Linus doesn't use PGP, which is why I didn't sign my
original mail. Certainly developers who send in their PGP public
keys would check the next version that is published and make sure
that they key that went in the CREDITS file is indeed their own.

However, you are right -- if someone is forging a key, they are
likely to forge the key of someone who doesn't use PGP, or doesn't
use PGP enough to think of checking the CREDITS file...

Since I came up with this crazy idea, perhaps I should volunteer
to try to keep an eye on the PGP keys inserted in the CREDITS
file. It would be low-security surveilance; I would just contact
people at the email address listed (and try to check an earlier
CREDITS file to make sure that they email address didn't change
at the same time, unless I recognized the new email address) saying
something like
"This is an automatically generated notice:

A PGP key has recently been added in your name to the Linux kernel
source CREDITS file. The entry is:
P: .........

If this entry is incorrect please send a correct entry to Linus
Torvalds <Linus.Torvalds@Helsinki.FI> immediately.

If you never sent your PGP key to Linus, then someone may be
attempting to forge email in your name. This is especially likely
to be true if you do not even have a PGP key. In that case, ask
Linus to remove the entry.

Thank you."

Hopefully that will help keep Linus from having to deal with any
more overhead and still provide us with as much security as we
can have without having actually met and signed keys...

Any opinions? Is it worth doing?

>To that end I'm hoping to organize a PGP Key signing party at the
>Berlin Linux Conference, since we will hopefully have a large number of
>Linux developers there.

Hopefully this will help solve the problem more effectively and
thoroughly...

michaelkjohnson