Re: PGP signing releases - Mailing list pgsql-hackers

Having just started working with GPG I shouldn't be considered an expert but
it seems to me that each core developer should create a key and should
cross-sign each others' keys to form a web of trust to verify the
authenticity of those signatures. In any case, I think that if
security-related projects like GnuPG and OpenSSH use the individual method
then it wouldn't be a bad idea to follow their lead.

One hopes that situations like last week's "ousting" of one of the core
FreeBSD developers
(http://slashdot.org/article.pl?sid=03/02/03/239238&mode=thread&tid=122&tid=156)
are rare but if such a situation were to arise, a shared project key would be
Very Bad (tm).

If I understand GPG correctly, one can create a "detached signature" of a
document. As such, any or all of the core developers could create and post
such a signature and a user could verify against as many signatures as
desired to feel secure that the file is good.

Cheers,
Steve


On Tuesday 04 February 2003 9:15 am, greg@turnstep.com wrote:
> There are generally two ways to do it: have a "project" key, or have
> each developer use their own key. The advantage of the first way is
> that each release is signed by the same key, which is clearly
> associated with the project. The disadvantage is control, security,
> and accountablility. The second way pretty much reverses the
> arguments: each key is controlled by one person, but there is no
> obvious mapping between that person and the project. Individual keys
> also have a history associated with them, and are usually already
> integrated into the Web of Trust.
>
> Many projects use the individual method, including Apache, GnuPG, and
> OpenSSH. Some use the project method, such as sendmail and proftpd.
> Either is okay with me, but some questions need to be answered if
> using a project key:
>
> Who will actually hold the key? Where will it be physically kept?
>
> How many people will know the passphrase?
>
> Who will be responsible for signing the files? Is there a backup person?
>
> Will it be a signing-only key? What size? Should it expire?
>
> How is verification of the files before signing accomplished?
>
>
> I've got some ideas about most of those, especially the last two. This will
> not be that easy of a process, but on the other hand, new versions do not
> appear very frequently, and it is important to get this right the first
> time.