PGP signing releases

Neil Conway <neilc@samurai.com> writes:

I think we should PGP sign all the "official" packages that are provided
for download from the various mirror sites.

This is probably a good idea.

I'd volunteer to do the work myself, except that it's pretty closely
intertwined with the release process itself...

Marc would have to be the guy who actually generates the tarball
signatures. But you could possibly help him get the procedure set up,
if he's not familiar with it already...

regards, tom lane

On Sun, 2003-02-02 at 18:39, Neil Conway wrote:

Folks,

I think we should PGP sign all the "official" packages that are provided
for download from the various mirror sites. IMHO, this is important
because:

- ensuring that end users can trust PostgreSQL is an important part to
getting the product used in mission-critical applications, as I'm sure
you all know. Part of that is producing good software; another part is
ensuring that users can trust that the software we put out hasn't been
tampered with.

- people embedding trojan horses in open source software is not unheard
of. In fact, it's probably becoming more common: OpenSSH, sendmail,
libpcap/tcpdump and bitchx have all been the victim of trojan horse
attacks fairly recently.

- PGP signing binaries is relatively easy, and doesn't need to be done
frequently.

Comments?

I'd volunteer to do the work myself, except that it's pretty closely
intertwined with the release process itself...

Cheers,

Neil

Actually, if you just had everyone sign the "official" key and submit it
back to the party that's signing, that would probably be good enough.
Basically, as long as people can verify the package has been signed and
can reasonably verify that the signing key is safe and/or can be
verified, confidence should be high in the signed package.

I certainly have no problem with people signing my key nor with signing
others as long as we can verify/authenticate each others keys prior.

Regards,

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

On Sun, 2 Feb 2003, Neil Conway wrote:

Folks,

I think we should PGP sign all the "official" packages that are provided
for download from the various mirror sites. IMHO, this is important
because:

- ensuring that end users can trust PostgreSQL is an important part to
getting the product used in mission-critical applications, as I'm sure
you all know. Part of that is producing good software; another part is
ensuring that users can trust that the software we put out hasn't been
tampered with.

right, that is why we started to provide md5 checksums ...

I'd volunteer to do the work myself, except that it's pretty closely
intertwined with the release process itself...

well, if you want to tell me the steps, I'll consider it ...

On Sunday 02 February 2003 21:23, Marc G. Fournier wrote:

On Sun, 2 Feb 2003, Neil Conway wrote:

I think we should PGP sign all the "official" packages that are provided
for download from the various mirror sites. IMHO, this is important
because:

right, that is why we started to provide md5 checksums ...

Actually this impacts RPMs more than the tarball, although the tarball's md5
sums are important. I have been intending to do this for some time; maybe
it's time to bite the bullet.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

"Marc G. Fournier" <scrappy@hub.org> writes:

On Sun, 2 Feb 2003, Neil Conway wrote:

- ensuring that end users can trust PostgreSQL is an important part to
getting the product used in mission-critical applications, as I'm sure
you all know. Part of that is producing good software; another part is
ensuring that users can trust that the software we put out hasn't been
tampered with.

right, that is why we started to provide md5 checksums ...

The md5 checksum is useful as a cross-check that you've got a clean
copy, but it doesn't prove that the copy on the FTP site hasn't been
tampered with. Someone who's managed to break into the FTP server
could replace the tarball with a trojaned version *and* alter the md5
file to match. The point of a PGP signature is that only someone who
has the corresponding secret key could make a signature file that
matches the tarball and the public key.

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think we should PGP sign all the "official" packages that are
provided for download from the various mirror sites.

Doesn't anyone around here read pgsql-general? :) I've been arguing for
this over there since June of last year. I've also been signing the
checksums with PGP and posting those to the mailing list.

If this is done (and I am very glad to see a renewed interest forming),
I'd like to see it done the correct way - it's too easy to get this wrong
and could actually decrease the security of the project by providing a
false sense of security. I think this list would be a good place to discuss
how it would be implemented.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200302030948
-----BEGIN PGP SIGNATURE-----
Comment: http://www.gtsm.com/pgp.html

iD8DBQE+PoGQvJuQZxSWSsgRAinkAJ9HViGZIfWVvX8RswLsNfec7ln6yQCfbO+L
WjSKSr61QKkfpL6Ax0vt4Ag=
=0MK8
-----END PGP SIGNATURE-----

On Sun, 2003-02-02 at 21:23, Marc G. Fournier wrote:

well, if you want to tell me the steps, I'll consider it ...

I certainly wouldn't consider myself to be an expert in PGP, but my
understanding of the basic steps is:

(1) Generate a public/private key pair for the PGDG team. This should be
used to sign all "official" packages.

(2) Have this PK signed by various people who can actually verify that
Marc Fournier == 'that PGP key' == 'PGDG member'.

(2) Upload the public key to PGP keyservers, like keyserver.net,
www.pgp.net, etc. as well as provide a copy of the public key on
www.postgresql.org and ftp.postgresql.org

(3) Sign official releases using the PGDG private key, and provide the
signatures on www.postgresql.org along with the packages themselves.

If someone more experienced in the use of PGP would like to comment,
please go ahead.

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

(3) Sign official releases using the PGDG private key, and provide the
signatures on www.postgresql.org along with the packages themselves.

Sounds about right. I'd go as far as to sign release announcements and
security emails as well.

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

On Sun, 2003-02-02 at 20:23, Marc G. Fournier wrote:

right, that is why we started to provide md5 checksums ...

md5 checksums only validate that the intended package (trojaned or
legit) has been properly received. They offer nothing from a security
perspective unless the checksums have been signed with a key which can
be readily validated from multiple independent sources.

Regards,

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

On Mon, Feb 03, 2003 at 12:24:14PM -0600, Greg Copeland wrote:

On Sun, 2003-02-02 at 20:23, Marc G. Fournier wrote:

right, that is why we started to provide md5 checksums ...

md5 checksums only validate that the intended package (trojaned or
legit) has been properly received. They offer nothing from a security
perspective unless the checksums have been signed with a key which can
be readily validated from multiple independent sources.

If you can get the md5 sum of "multiple independent sources",
it's about the same thing. It all depends on how much you trust
those sources.

I'm not saying md5 is as secure as pgp, not at all, but you can't
trust those pgp keys to be the real one either.

Kurt

On Mon, 3 Feb 2003, Kurt Roeckx wrote:

I'm not saying md5 is as secure as pgp, not at all, but you can't
trust those pgp keys to be the real one either.

Sure you can. Just verify that they've been signed by someone you trust.

For example, next time I happen to run into Bruce Momjian, I hope he'll
have his PGP key fingerprint with him. I can a) verify that he's the
same guy I who, under the name "Bruce Momjian," was giving the seminar I
went to last weekend, and b) check his passport ID to see that the U.S.
government believes that someone who looks him is indeed "Bruce Momjian"
and a U.S. citizen. That, for me, is enough to trust that he is who he
says he is when he gives me the fingerprint.

I take that fingerprint back to my computer and verify that the key I
downloaded from the MIT keyserver has the same fingerprint. Then I sign
that key with my own signature, assigning it an appropriate level of trust.

Next time I download a postgres release, I then grab a copy of the
postgres release-signing public key, and verify that its private key was
used to sign the postgres release, and that it is signed by Bruce's key.

Now I have a direct chain of trust that I can evaluate:

1. Do I believe that the person I met was indeed Bruce Momjian?

2. Do I trust him to take care of his own key and be careful signing
other keys?

3. Do I trust his opinion that the postgres release-signing key that
he signed is indeed valid?

4. Do I trust the holder of the postgres release-signing key to have
taken care of the key and have been careful about signing releases
with it?

Even if you extend this chain by a couple of people, that's trust in a
lot fewer people than you're going to need if you want to trust an MD5
signature.

cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Mon, 2003-02-03 at 13:55, Kurt Roeckx wrote:

On Mon, Feb 03, 2003 at 12:24:14PM -0600, Greg Copeland wrote:

On Sun, 2003-02-02 at 20:23, Marc G. Fournier wrote:

right, that is why we started to provide md5 checksums ...

md5 checksums only validate that the intended package (trojaned or
legit) has been properly received. They offer nothing from a security
perspective unless the checksums have been signed with a key which can
be readily validated from multiple independent sources.

If you can get the md5 sum of "multiple independent sources",
it's about the same thing. It all depends on how much you trust
those sources.

I'm not saying md5 is as secure as pgp, not at all, but you can't
trust those pgp keys to be the real one either.

No, that is not the same thing at all. PKI specifically allows for "web
of trust". Nothing about md5 checksums allows for this. As such,
chances are, if a set of md5 checksums have been forged, they will be
propagated and presented as being valid even though they are not.

I'll say this again. Checksums alone offers zero security protection.
It was never intended to address that purpose. As such, it does not
address it. If you need security, use a security product. Checksums
ONLY purpose is to ensure copy propagation validation. It does not
address certification of authenticity in any shape or form.

As for trusting the validity of the keys contained within a PKI, that's
where the whole concept of "web of trust" comes into being. You can
ignore it and not benefit or you can embrace it, as people are
advocating, and leverage it.

Validation of keys can be as simple as snail-mail, phone calls, and
fingerprint validation. It's that simple. It's why fingerprints exist
in the first place.

Regards,

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

On Mon, 2003-02-03 at 22:35, Curt Sampson wrote:

On Mon, 3 Feb 2003, Kurt Roeckx wrote:

I'm not saying md5 is as secure as pgp, not at all, but you can't
trust those pgp keys to be the real one either.

Sure you can. Just verify that they've been signed by someone you trust.

For example, next time I happen to run into Bruce Momjian, I hope he'll
have his PGP key fingerprint with him. I can a) verify that he's the
same guy I who, under the name "Bruce Momjian," was giving the seminar I
went to last weekend, and b) check his passport ID to see that the U.S.
government believes that someone who looks him is indeed "Bruce Momjian"
and a U.S. citizen. That, for me, is enough to trust that he is who he
says he is when he gives me the fingerprint.

I take that fingerprint back to my computer and verify that the key I
downloaded from the MIT keyserver has the same fingerprint. Then I sign
that key with my own signature, assigning it an appropriate level of trust.

Next time I download a postgres release, I then grab a copy of the
postgres release-signing public key, and verify that its private key was
used to sign the postgres release, and that it is signed by Bruce's key.

Now I have a direct chain of trust that I can evaluate:

1. Do I believe that the person I met was indeed Bruce Momjian?

2. Do I trust him to take care of his own key and be careful signing
other keys?

3. Do I trust his opinion that the postgres release-signing key that
he signed is indeed valid?

4. Do I trust the holder of the postgres release-signing key to have
taken care of the key and have been careful about signing releases
with it?

Even if you extend this chain by a couple of people, that's trust in a
lot fewer people than you're going to need if you want to trust an MD5
signature.

cjs

And that's the beginning of the web of trust. ;) Worth noting that
snail-mail and phone calls can easily play a role in this process as
well. I think if USPO can play a role in delivering master keys for pin
pads used by banks across America and the around the world, surely it's
good enough to help propagate key information for signing packages.

Regards,

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

On Mon, 2003-02-03 at 22:35, Curt Sampson wrote:

2. Do I trust him to take care of his own key and be careful signing
other keys?

3. Do I trust his opinion that the postgres release-signing key that
he signed is indeed valid?

4. Do I trust the holder of the postgres release-signing key to have
taken care of the key and have been careful about signing releases
with it?

Sorry to respond again, however, I did want to point out, signing a key
does not have to imply an absolute level of trust of the signer. There
are several trust levels. For example, if we validated keys via phone
and mail, I would absolutely not absolutely trust the key I'm signing.
However, if I had four people which mostly trusted the signed key and
one or two which absolutely trusted the signed key whom I absolutely
trust, then it's a fairly safe bet I too can trust the key. Again, this
all comes back to building a healthy web of trust.

Surely there are a couple of key developers whom would be willing to
sign each other's keys and have previously met before. Surely this
would be the basis for phone validation. Then, of course, there is 'ol
snail-mail route too. Of course, nothing beats meeting in person having
valid ID and fingerprints "in hand." ;)

Regards,

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

On Tue, 3 Feb 2003, Greg Copeland wrote:

Surely there are a couple of key developers whom would be willing to
sign each other's keys and have previously met before. Surely this
would be the basis for phone validation. Then, of course, there is 'ol
snail-mail route too. Of course, nothing beats meeting in person having
valid ID and fingerprints "in hand." ;)

I should mention, I'm not always so paranoid that I check ID and all of
that. It really depends on how well I know the person. I've met Bruce only
once, so I wouldn't do it over the phone at all, since we don't share much
non-public background and I'm not dead certain that I could tell his voice
from a similar one. The same is not true when it comes to doing this with
some of my close friends.

cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Mon, Feb 03, 2003 at 22:55:12 -0600,
Greg Copeland <greg@CopelandConsulting.Net> wrote:

I'll say this again. Checksums alone offers zero security protection.
It was never intended to address that purpose. As such, it does not
address it. If you need security, use a security product. Checksums
ONLY purpose is to ensure copy propagation validation. It does not
address certification of authenticity in any shape or form.

Checksums can be used for security in that they can be transmitted through
alternative channels using lower bandwidth than that used for the raw data.
(They are also what is normally signed by asymmetric keys for performance
reasons.).

And note that even signing the releases only protects against some kinds
of problems. If someone breaks into the CVS server shortly before a release,
they could change the source code and have a reasonable chance that the change
would go unnoticed for long enough to make it into a release. There are also
circumstances that the developers might be compromised (at least from the
standpoint of the downloaders). I wouldn't be that surprised if under pressure
from the FBI the developers might cooperate in getting a trojaned copy of
the database server into the hands of someone the FBI was interested in.
(Ogranized crime really should be supporting open source since they really
need software they can trust and it is a lot easier to check for trojaned
source, than it is for trojaned binaries.) Large amounts of money could also
produce the same result. I don't think either of those scenarios is likely,
but they are possible.

Signing the releases is a good idea, but they aren't going to be a 100%
guarenty against trojans.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200302041207

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE+P/XQvJuQZxSWSsgRAuKEAJwPKMe/nlBIk/Qm/dh2BbPvXbUQ4gCfeVqD
8TkRv3JkZ9T7t2YYBaCVc24=
=RnK6
-----END PGP SIGNATURE-----

On Tue, Feb 04, 2003 at 01:35:47PM +0900, Curt Sampson wrote:

On Mon, 3 Feb 2003, Kurt Roeckx wrote:

I'm not saying md5 is as secure as pgp, not at all, but you can't
trust those pgp keys to be the real one either.

Sure you can. Just verify that they've been signed by someone you trust.

I know how it works, it's just very unlikely I'll ever meet
someone so it gives me a good chain.

Anyway, I think pgp is good thing to do, just don't assume that
it's always better then just md5.

Kurt

On Tue, 2003-02-04 at 12:55, Kurt Roeckx wrote:

On Tue, Feb 04, 2003 at 01:35:47PM +0900, Curt Sampson wrote:

On Mon, 3 Feb 2003, Kurt Roeckx wrote:

I'm not saying md5 is as secure as pgp, not at all, but you can't
trust those pgp keys to be the real one either.

Sure you can. Just verify that they've been signed by someone you trust.

I know how it works, it's just very unlikely I'll ever meet
someone so it gives me a good chain.

Anyway, I think pgp is good thing to do, just don't assume that
it's always better then just md5.

Not necessarily better -- but it's always as good as md5.

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc