Thread: PGP signing releases
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 -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
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 aboutsigning 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 alllight. --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 alllight. --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
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.
Comments intermixed below. On Tue, 2003-02-04 at 12:04, Steve Crawford wrote: > 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 This is a good idea regardless as which "key" approach is used. Being able to reliably trust a key is only as strong as the associated "web of trust." > 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. > There are pros and cons associated with each approach. Neither is really better IMO. If three people are required to sign a package prior to release, what happens when one of them is unavailable for signing (vacation, hospital, etc). This is one of the reasons why having a single project key which the core developers sign may appear to be easier. > 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 a revocation key has been properly generated (as it should of been), this is not a problem at all. The revocation key is quickly shot over to the known key servers and included with the newly generated project key. As people add and confirm the new project key, the old key is automatically revoked. Again, if this is properly handled, it is not much of a problem at all. PKI, by means of revocation keys, specifically addresses this need. > 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 > IIRC, PGP and GPG both support detached signatures. > > > > Who will actually hold the key? Where will it be physically kept? Good question but can usually be addressed. > > > > How many people will know the passphrase? As few as possible. Ideally only two, maybe three core developers. One could also only allow a single person to hold the passphrase and divide it into parts between two or more. This is commonly done in financial circles. The exact details will be mostly driven by the key approach that is picked. > > > > Who will be responsible for signing the files? Is there a backup person? > > This is important to make sure that any backup people are properly included in the "web of trust" from the very beginning. > > Will it be a signing-only key? What size? Should it expire? > > Keys should always expire. If you want to allow for one year, two year, or even maybe three years, that's fine. Nonetheless, expiration should always be built in, especially on a project like this where people may be more transient. > > How is verification of the files before signing accomplished? > > The person creating the initial package release should also initially sign it. From there, the web of trust for the people signing it can work as designed. Once the initial package has been generated, it should not leave his eyes until it has been signed. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
On Tue, 2003-02-04 at 12:02, Rod Taylor wrote: > 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. Even improperly used, digital signatures should never be worse than simple checksums. Having said that, anyone that is trusting checksums as a form of authenticity validation is begging for trouble. Checksums are not, in of themselves, a security mechanism. I can't stress this enough. There really isn't any comparison here. Please stop comparing apples and oranges. No matter how hard you try, you can not make orange juice from apples. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote: > > Even improperly used, digital signatures should never be worse than > simple checksums. Having said that, anyone that is trusting checksums > as a form of authenticity validation is begging for trouble. Should I point out that a "fingerprint" is nothing more than a hash? > Checksums are not, in of themselves, a security mechanism. So a figerprint and all the hash/digest function have no purpose at all? > There really isn't any comparison here. I didn't say you could compare the security offered by both of them. All I said was that md5 also makes sense from a security point of view. Should I also point out that md5 really isn't a "checksum", it's a digest or hash. I have to agree that a real checksum, where you just add all the bytes, offers no protection. Kurt
On Tue, 4 Feb 2003, Kurt Roeckx wrote: > I know how it works, it's just very unlikely I'll ever meet > someone so it gives me a good chain. One postgresql conference is all it takes. > Anyway, I think pgp is good thing to do, just don't assume that > it's always better then just md5. I think it is. Even if you can't personally trust the signature properly, it offers much more opportunity to discover a forgery because if you grab the signing key when it's first published, the aquisition of the key and the potentially forged binary are separated in time, making substitution of both much more difficult. Someone can easily change an MD5 signature file that's sitting right next to a binary on an FTP server. Someone can not easily change a PGP key that's already sitting in your keyring on your computer. 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 alllight. --XTC
On Tue, 4 Feb 2003, Kurt Roeckx wrote: > > There really isn't any comparison here. > > I didn't say you could compare the security offered by both of > them. All I said was that md5 also makes sense from a security > point of view. MD5, or any other unsigned check, makes sense from a security point of view only if it is stored independently from the thing you are checking. So NetBSDs package system MD5 hashes help a little with security. (You'd have to modify both those on the NetBSD FTP server or anoncvs or whatever *and* the binary on an independently run FTP server.) If the "security token" is stored with the item to be secured (i.e., on the same FTP server) and is unsigned, it is just as subject to modification as the item itself, and provides no extra security. 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 alllight. --XTC
On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote: > On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote: > > > > Even improperly used, digital signatures should never be worse than > > simple checksums. Having said that, anyone that is trusting checksums > > as a form of authenticity validation is begging for trouble. > > Should I point out that a "fingerprint" is nothing more than a > hash? > You seem to not understand the part where I said, "in of themselves." Security is certainly an area of expertise where the devil is in the details. One minor detail can greatly effect the entire picture. You're simply ignoring all the details and looking for obtuse parallels. Continue to do so all you like. It still doesn't effectively and reliably address security in the slightest. > > Checksums are not, in of themselves, a security mechanism. > > So a figerprint and all the hash/digest function have no purpose > at all? > This is just getting silly and bordering on insulting. If you have meaningful comments, please offer them up. Until such time, I have no further comments for you. Obviously, a fingerprint is derivative piece of information which, in of it self, does not validate anything. Thusly, the primary supporting concept is the "web of trust", associated process and built in mechanisms to help ensure it all makes sense and maintained in proper context. Something that a simple MD5 checksum does not provide for. Not in the least. A checksum or hash only allows for comparisons between two copies to establish they are the same or different. It, alone, can never reliably be a source of authentication and validation. A checksum or hash, alone, says nothing about who created it, where it came from, how old it is, or whom is available to readily and authoritatively assist in validation of the checksummed (or hashed) entity or the person who created it. I do agree that a checksum (or hash) is better than nothing, however, a serious security solution it is not. Period. Feel free to be lulled into complacent comfort. In the mean time, I'll choose a system which actually has a chance at working. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote: > On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote: > > > > Even improperly used, digital signatures should never be worse than > > simple checksums. Having said that, anyone that is trusting checksums > > as a form of authenticity validation is begging for trouble. > > Should I point out that a "fingerprint" is nothing more than a > hash? Since someone already mentioned MD5 checksums of tar files versus PGP key fingerprints, perhaps things will become a bit clearer here if I point out that the important point is not that these are both hashes of some data, but that the time and means of acquisition of that hash are entirely different between the two. 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 alllight. --XTC
----- Original Message ----- From: "Kurt Roeckx" <Q@ping.be> > > Should I point out that a "fingerprint" is nothing more than a > hash? > If somebody shows you their passport to prove who they are and then gives you a fingerprint of their PGP key, they have implicitly signed that fingerprint. By contrast, a simple MD5 checksum of a binary sitting on the same server is effectively unsigned. You might like to do a little reading on PKI and how it works, before you make further comment. cheers andrew
On Tue, Feb 04, 2003 at 23:13:47 +0100, Kurt Roeckx <Q@ping.be> wrote: > > So a figerprint and all the hash/digest function have no purpose > at all? The purpose of both is to reduce the amount of material in a way that makes it hard to generate some other material that would result in the same hash or fingerprint. This allows you to reduce the cost of transmitting the data or making computations (in particular signing) on the data.
On Wed, 4 Feb 2003, Greg Copeland wrote: > If three people are required to sign a package prior to release, > what happens when one of them is unavailable for signing (vacation, > hospital, etc). This is one of the reasons why having a single project > key which the core developers sign may appear to be easier. I don't see that it makes that much difference. So the release is signed only by, say, only three people instead of four. It's still signed. > > One hopes that situations like last week's "ousting" of one of the > > core FreeBSD developers are rare but if such a situation were to > > arise, a shared project key would be Very Bad (tm). > > If a revocation key has been properly generated (as it should of been), > this is not a problem at all. Actually, it is still a problem. Revocations are not reliable in PGP, and there's really no way to make them perfectly reliable in any system, because you've got no way to force the user to check that his "cached data" (i.e., the key he holds in his keyring) is still valid. This is why we generally expire signing keys and certificates and stuff like that on a regular basis. This one element alone makes me think that individual signing is a better thing. (With individual signing you'd have to compromise several keys before you have to start relying on revocation certificates.) > > > Who will actually hold the key? Where will it be physically kept? > > Good question but can usually be addressed. It can be addressed, but how well? This is another big issue that I don't see any plan for that I'm comfortable with.. > > > How many people will know the passphrase? > > As few as possible. Ideally only two, maybe three core developers. Um...I'm not sure that this is a relevant question at all. The passphrase is not part of the key; it's just used to encrypt the key for storage. If you know the passphrase, you can make unlimited copies of the key, and these copies can be protected with any passphrases you like, or no passphrase, for that matter. > One could also only allow a single person to hold the passphrase and > divide it into parts between two or more. This is commonly done in > financial circles. Hm. Splitting the key into parts is a very interesting idea, but I'd be interested to know how you might implement it without requiring everybody to be physically present at signing. 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 alllight. --XTC
On Wed, Feb 05, 2003 at 15:22:12 +0900, Curt Sampson <cjs@cynic.net> wrote: > On Wed, 4 Feb 2003, Greg Copeland wrote: > > Hm. Splitting the key into parts is a very interesting idea, but I'd > be interested to know how you might implement it without requiring > everybody to be physically present at signing. The simple way to do this is to make it known to the community that postgresql releases should be signed by at least X of the developers.
On Wed, 2003-02-05 at 00:22, Curt Sampson wrote: > On Wed, 4 Feb 2003, Greg Copeland wrote: > > > If three people are required to sign a package prior to release, > > what happens when one of them is unavailable for signing (vacation, > > hospital, etc). This is one of the reasons why having a single project > > key which the core developers sign may appear to be easier. > > I don't see that it makes that much difference. So the release is signed > only by, say, only three people instead of four. It's still signed. > Note that I said "appear to be easier", not that it actually is easier an any meaningful way. Some of the more paranoid will look for consistency from those that sign the package in question. The fact different people sign may be the cause of additional footwork for some. Which probably isn't such a bad thing. Nonetheless, it could be a sign of alarm for a few. > > > One hopes that situations like last week's "ousting" of one of the > > > core FreeBSD developers are rare but if such a situation were to > > > arise, a shared project key would be Very Bad (tm). > > > > If a revocation key has been properly generated (as it should of been), > > this is not a problem at all. > > Actually, it is still a problem. Revocations are not reliable in PGP, > and there's really no way to make them perfectly reliable in any system, > because you've got no way to force the user to check that his "cached > data" (i.e., the key he holds in his keyring) is still valid. This is why > we generally expire signing keys and certificates and stuff like that on > a regular basis. > When a package is released which has a new key signing it, revocation should normally be found fairly quickly. This is especially true if it's included in the package AND from normal PKI routes. Revocation should accompany any packages which later follow until the key in question has expired. > This one element alone makes me think that individual signing is a > better thing. (With individual signing you'd have to compromise several > keys before you have to start relying on revocation certificates.) > > > > > Who will actually hold the key? Where will it be physically kept? > > > > Good question but can usually be addressed. > > It can be addressed, but how well? This is another big issue that I > don't see any plan for that I'm comfortable with.. > The reason I was vague is because it depends on the key route. Obviously, if each person signs, each person must protect their own key. If there is a central project key, it's simply a matter of determining which box is used for signing, etc...while important, it's certainly not difficult to address. > > > > How many people will know the passphrase? > > > > As few as possible. Ideally only two, maybe three core developers. > > Um...I'm not sure that this is a relevant question at all. The > passphrase is not part of the key; it's just used to encrypt the key for > storage. If you know the passphrase, you can make unlimited copies of > the key, and these copies can be protected with any passphrases you like, > or no passphrase, for that matter. > If you're concerned about this to that extent, clearly those people should not part of the web of trust nor should they be receiving the passphrase nor a copy of the private key. Remember, trust is a key (pun intended) part of a reliable PKI. > > One could also only allow a single person to hold the passphrase and > > divide it into parts between two or more. This is commonly done in > > financial circles. > > Hm. Splitting the key into parts is a very interesting idea, but I'd > be interested to know how you might implement it without requiring > everybody to be physically present at signing. > > cjs I was actually talking about splitting the passphrase, however, splitting the key is certainly possible as well. Having said that, if a private key is shared, it should still be encrypted. As such, a passphrase should still be considered; as will splitting it. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
On Tue, Feb 04, 2003 at 06:19:42PM -0600, Greg Copeland wrote: > > I do agree that a checksum (or hash) is better than nothing, however, a > serious security solution it is not. Which really is all I'm saying. Kurt
On Thu, 5 Feb 2003, Greg Copeland wrote: > > > > > Who will actually hold the key? Where will it be physically kept? > > > > > > Good question but can usually be addressed. > > > > It can be addressed, but how well? This is another big issue that I > > don't see any plan for that I'm comfortable with.. > > The reason I was vague is because it depends on the key route. > Obviously, if each person signs, each person must protect their own > key. If there is a central project key, it's simply a matter of > determining which box is used for signing, etc...while important, it's > certainly not difficult to address. It seems to me extremely difficult to address. Unless you are physically monitoring someone, how do you prevent someone from copying the key off of that machine. At which point anybody with the passphrase can use it for anything. > > > > > How many people will know the passphrase? > > > > > > As few as possible. Ideally only two, maybe three core developers. > > > > Um...I'm not sure that this is a relevant question at all. The > > passphrase is not part of the key; it's just used to encrypt the key for > > storage. If you know the passphrase, you can make unlimited copies of > > the key, and these copies can be protected with any passphrases you like, > > or no passphrase, for that matter. > > If you're concerned about this to that extent, clearly those people > should not part of the web of trust nor should they be receiving the > passphrase nor a copy of the private key. Remember, trust is a key (pun > intended) part of a reliable PKI. In that case, I would trust only one person with the key. Making copies of the key for others gives no additional protection (since it takes only one person out of the group to sign the release) while it increases the chance of key compromise (since there are now more copies of the key kicking around, and more people who know the passphrase). Keys cannot be transfered from one person to another since, being digital data, there's no way to ascertain that the original holder does not still (on purpose or inadvertantly) have copies of the key. So in the case where we want to transfer trust from one person to another, we must also generate a new key and revoke the old one. This is now exactly equivalant to having each developer sign postgres with a signing key (signed by his main key) for which the other developers (or appropriate authority) have a revocation certificate. And back to the passphrase issue, once again, can't you see that it's completely irrelevant? At some point, someone who knows the passphrase is going to have to be in a position to use that to decrypt the key. At that point he has the key, period. Changing the passphrase does no good, because you can't change the passphrase on the copy of the key he may have made. A passphrase is like a lock on your barn door. After you've given someone the key and he's gone in and taken the cow, changing the lock gives you no protection at all. 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 alllight. --XTC
On Tue, 2003-02-04 at 18:27, Curt Sampson wrote: > On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote: > > On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote: > > > > > > Even improperly used, digital signatures should never be worse than > > > simple checksums. Having said that, anyone that is trusting checksums > > > as a form of authenticity validation is begging for trouble. > > > > Should I point out that a "fingerprint" is nothing more than a > > hash? > > Since someone already mentioned MD5 checksums of tar files versus PGP > key fingerprints, perhaps things will become a bit clearer here if I > point out that the important point is not that these are both hashes of > some data, but that the time and means of acquisition of that hash are > entirely different between the two. And that it creates a verifiable chain of entities with direct associations to people and hopefully, email addresses. Meaning, it opens the door for rapid authentication and validation of each entity and associated person involved. Again, something a simple MD5 hash does not do or even allow for. Perhaps even more importantly, it opens the door for rapid detection of corruption in the system thanks to revocation certificates/keys. In turn, allows for rapid repair in the event that the worst is realized. Again, something a simple MD5 does not assist with in the least. Thanks Curt. -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To answer some of my earlier questions, here is one specific way of doing it: Tom Lane creates a PostgreSQL key, signing only, DSA, 1024 bits, that expires in 3 years. It ends up looking something like this: pub 1024D/0BB10D1D 2003-02-07 PostgreSQL (PostgreSQL signing key) <key@postgresql.org> Tom keeps a close watch on the commits list and waits for a new version to be released. When the tarball is made, he checks it out and when satisfied, he signs it with the key. (Other people can look it over and verify it by referring to its sha1sum). Once signed, the small text file that is created is mailed to the web group (or just posted to the list). Somebody adds it to the web page, and from there to all the mirrors. Tom keeps the key secure, preferably by not keeping it on a box connected to the net. He generates a revocation certificate and gives it to Bruce, who squirrels it away until needed. Tom signs the key with his own, and perhaps with other developers who have PGP keys. People meet Tom at the conferences, exchange keys, the Web of Trust grows, and all is good in the world again. I chose Tom because he is part of the core and has (IMO) the best ability to detect problems in the source code and verify a final tarball. It doesn't really matter who has the key, actually, as long as they are sufficiently careful/paranoid about keeping it safe and offline, and at least one person in the core group has the ability to revoke it in case of an emergency. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200302071451 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+RBJovJuQZxSWSsgRAh3XAJ47eL56YmSKXJCtdAsyYzByMi+m2QCcCNjm b1tQyp1zLxkpGjhUer6FpZQ= =Hfpu -----END PGP SIGNATURE-----
Curt Sampson writes: > MD5, or any other unsigned check, makes sense from a security point of > view only if it is stored independently from the thing you are checking. So you put the MD5 sum into the release announcement email. That is downloaded by many people and also archived in many distributed places that we don't control, so it would be very hard to tamper with. ISTM that this gives you the same result as a PGP signature but with much less administrative overhead. -- Peter Eisentraut peter_e@gmx.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > So you put the MD5 sum into the release announcement email. That is > downloaded by many people and also archived in many distributed places > that we don't control, so it would be very hard to tamper with. > ISTM that this gives you the same result as a PGP signature but with > much less administrative overhead. Not the same results. For one thing, the mailing announcement may be archived on google, but asking people to search google for an MD5 sum as they download the tarball is hardly feasible. Second, it still does not prevent someone from breaking into the server and replacing the tarball with their own version, and their own MD5 checksum. Or maybe just one of the mirrors. Users are not going to know to compare that MD5 with versions on the web somewhere. Third, is does not allow a positive history to be built up due to signing many releases over time. With PGP, someone can be assured that the 9.1 tarball they just downloaded was signed by the same key that signed the 7.3 tarball they've been using for 2 years. Fourth, only with PGP can you trace your key to the one that signed the tarball, an additional level of security. MD5 provides an integrity check only. Any security it affords (such as storing the MD5 sum elsewhere) is trivial and should not be considered when using PGP is standard, easy to implement, and has none of MD5s weaknesses. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200302102250 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+SA4AvJuQZxSWSsgRAhenAKDu0vlUBC5Eodyt2OxTG6el++BJZACguR2i GGLAzhtA7Tt9w4RUYXY4g2U= =3ryu -----END PGP SIGNATURE-----
Well said. I'm glad someone else is willing to take a stab at addressing these issues, since I've been down with the flu. Thanks Greg. As both Gregs have pointed out, hashes and checksums alone should only be used as an integrity check. It is not a viable security mechanism. A hash does not provide for authentication and even more importantly, verification of authentication. These concepts are key to creating a secure environment. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting On Mon, 2003-02-10 at 21:57, greg@turnstep.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > So you put the MD5 sum into the release announcement email. That is > > downloaded by many people and also archived in many distributed places > > that we don't control, so it would be very hard to tamper with. > > ISTM that this gives you the same result as a PGP signature but with > > much less administrative overhead. > > Not the same results. For one thing, the mailing announcement may be > archived on google, but asking people to search google for an MD5 sum > as they download the tarball is hardly feasible. Second, it still does > not prevent someone from breaking into the server and replacing the > tarball with their own version, and their own MD5 checksum. Or maybe > just one of the mirrors. Users are not going to know to compare that > MD5 with versions on the web somewhere. Third, is does not allow a > positive history to be built up due to signing many releases over time. > With PGP, someone can be assured that the 9.1 tarball they just > downloaded was signed by the same key that signed the 7.3 tarball > they've been using for 2 years. Fourth, only with PGP can you trace > your key to the one that signed the tarball, an additional level of > security. MD5 provides an integrity check only. Any security it > affords (such as storing the MD5 sum elsewhere) is trivial and > should not be considered when using PGP is standard, easy to implement, > and has none of MD5s weaknesses. > > - -- > Greg Sabino Mullane greg@turnstep.com > PGP Key: 0x14964AC8 200302102250 > -----BEGIN PGP SIGNATURE----- > Comment: http://www.turnstep.com/pgp.html > > iD8DBQE+SA4AvJuQZxSWSsgRAhenAKDu0vlUBC5Eodyt2OxTG6el++BJZACguR2i > GGLAzhtA7Tt9w4RUYXY4g2U= > =3ryu > -----END PGP SIGNATURE----- > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
On Wed, 2003-02-05 at 18:53, Curt Sampson wrote: > On Thu, 5 Feb 2003, Greg Copeland wrote: > > > > > > > Who will actually hold the key? Where will it be physically kept? > > > > > > > > Good question but can usually be addressed. > > > > > > It can be addressed, but how well? This is another big issue that I > > > don't see any plan for that I'm comfortable with.. > > > > The reason I was vague is because it depends on the key route. > > Obviously, if each person signs, each person must protect their own > > key. If there is a central project key, it's simply a matter of > > determining which box is used for signing, etc...while important, it's > > certainly not difficult to address. > > It seems to me extremely difficult to address. Unless you are physically > monitoring someone, how do you prevent someone from copying the key off > of that machine. At which point anybody with the passphrase can use it > for anything. > This issue doesn't change regardless of the mechanism you pick. Anyone that is signing a key must take reasonable measures to ensure the protection of their key. > > > > > > How many people will know the passphrase? > > > > > > > > As few as possible. Ideally only two, maybe three core developers. > > > > > > Um...I'm not sure that this is a relevant question at all. The > > > passphrase is not part of the key; it's just used to encrypt the key for > > > storage. If you know the passphrase, you can make unlimited copies of > > > the key, and these copies can be protected with any passphrases you like, > > > or no passphrase, for that matter. > > > > If you're concerned about this to that extent, clearly those people > > should not part of the web of trust nor should they be receiving the > > passphrase nor a copy of the private key. Remember, trust is a key (pun > > intended) part of a reliable PKI. > > In that case, I would trust only one person with the key. Making copies of > the key for others gives no additional protection (since it takes only one > person out of the group to sign the release) while it increases the chance > of key compromise (since there are now more copies of the key kicking around, > and more people who know the passphrase). > Which brings us back to backups. Should the one person that has the key be unavailable or dead, who will sign the release? Furthermore, making *limited* copies of the key does provide for additional limited protection in case it's lost for some reason. This helps mitigate the use of the revocation key until it's absolutely required. Also provides for backup (of key and people). Basically, you are saying:You trust a core developerYou trust they can protect their keysYou trust they can properly distributetheir trustYou don't trust a core developer with a key Hmmm...something smells in your web of trust...So, which is it? Do you trust the core developers to protect the interests of the project and the associated key or not? If not, why trust any digital signature from them in the first place? Can't stress this enough. PKI is an absolute failure without trust. Period. > Keys cannot be transfered from one person to another since, being digital > data, there's no way to ascertain that the original holder does not still > (on purpose or inadvertantly) have copies of the key. So in the case where > we want to transfer trust from one person to another, we must also generate > a new key and revoke the old one. > No one is talking about transferring keys. In fact, I've previously addressed this topic, from a different angle, a number of times. We are talking about shared trust and not transfered trust. The transferring of trust is done by signing keys, not transferring keys. > This is now exactly equivalant to having each developer sign postgres > with a signing key (signed by his main key) for which the other > developers (or appropriate authority) have a revocation certificate. > > And back to the passphrase issue, once again, can't you see that it's > completely irrelevant? At some point, someone who knows the passphrase is > going to have to be in a position to use that to decrypt the key. At that > point he has the key, period. Changing the passphrase does no good, because > you can't change the passphrase on the copy of the key he may have made. > So you trust the core developer to sign the package but you don't trust him to have the key that's required to sign it? You can't have it both ways. > A passphrase is like a lock on your barn door. After you've given > someone the key and he's gone in and taken the cow, changing the lock > gives you no protection at all. I can assure you I fully understand the implications and meaning of everything I've said. -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
On Wed, 11 Feb 2003, Greg Copeland wrote: > On Wed, 2003-02-05 at 18:53, Curt Sampson wrote: > > [Re: everybody sharing a single key] > > This issue doesn't change regardless of the mechanism you pick. Anyone > that is signing a key must take reasonable measures to ensure the > protection of their key. Right. Which is why you really want to use separate keys: you can determine who compromised a key if it is compromised, and you can revoke one without having to revoke all of them. Which pretty much inevitably leads you to just having the developers use their own personal keys to sign the release. > Basically, you are saying: > You trust a core developer > You trust they can protect their keys > You trust they can properly distribute their trust > You don't trust a core developer with a key Not at all. I trust core developers with keys, but I see no reason to weaken the entire system by sharing keys when it's not necessary. Having each developer sign the release with his own personal key solves every problem you've brought up. 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 alllight. --XTC
On Tue, 2003-02-11 at 18:27, Curt Sampson wrote: > On Wed, 11 Feb 2003, Greg Copeland wrote: > > > On Wed, 2003-02-05 at 18:53, Curt Sampson wrote: > > > > [Re: everybody sharing a single key] > > > > This issue doesn't change regardless of the mechanism you pick. Anyone > > that is signing a key must take reasonable measures to ensure the > > protection of their key. > > Right. Which is why you really want to use separate keys: you can determine > who compromised a key if it is compromised, and you can revoke one without > having to revoke all of them. > > Which pretty much inevitably leads you to just having the developers use > their own personal keys to sign the release. > > > Basically, you are saying: > > You trust a core developer > > You trust they can protect their keys > > You trust they can properly distribute their trust > > You don't trust a core developer with a key > > Not at all. I trust core developers with keys, but I see no reason to > weaken the entire system by sharing keys when it's not necessary. Having > each developer sign the release with his own personal key solves every > problem you've brought up. > > cjs You need to keep in mind, I've not been advocating, rather, clarifying. The point being, having a shared key between trusted core developers is hardly an additional risk. After all, either they can be trusted or they can't. At this point, I think we both understand where the other stands. Either we agree or agree to disagree. The next step is for the developers to adopt which path they prefer to enforce and to ensure they have the tools and knowledge at hand to support it. Anyone know if Tom and Bruce know each other well enough to sign each other's keys outright, via phone, via phone and snail-mail? That would put us off to an excellent start. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
I hate to poo-poo this, but this "web of trust" sounds more like a "web of confusion". I liked the idea of mentioning the MD5 in the email announcement. It doesn't require much extra work, and doesn't require a 'web of %$*&" to be set up to check things. Yea, it isn't as secure as going through the motions, but if someone breaks into that FTP server and changes the tarball and MD5 file, we have much bigger problems than someone modifying the tarballs; our CVS is on that machine too. --------------------------------------------------------------------------- Greg Copeland wrote: > On Tue, 2003-02-11 at 18:27, Curt Sampson wrote: > > On Wed, 11 Feb 2003, Greg Copeland wrote: > > > > > On Wed, 2003-02-05 at 18:53, Curt Sampson wrote: > > > > > > [Re: everybody sharing a single key] > > > > > > This issue doesn't change regardless of the mechanism you pick. Anyone > > > that is signing a key must take reasonable measures to ensure the > > > protection of their key. > > > > Right. Which is why you really want to use separate keys: you can determine > > who compromised a key if it is compromised, and you can revoke one without > > having to revoke all of them. > > > > Which pretty much inevitably leads you to just having the developers use > > their own personal keys to sign the release. > > > > > Basically, you are saying: > > > You trust a core developer > > > You trust they can protect their keys > > > You trust they can properly distribute their trust > > > You don't trust a core developer with a key > > > > Not at all. I trust core developers with keys, but I see no reason to > > weaken the entire system by sharing keys when it's not necessary. Having > > each developer sign the release with his own personal key solves every > > problem you've brought up. > > > > cjs > > You need to keep in mind, I've not been advocating, rather, clarifying. > The point being, having a shared key between trusted core developers is > hardly an additional risk. After all, either they can be trusted or > they can't. > > At this point, I think we both understand where the other stands. > Either we agree or agree to disagree. The next step is for the > developers to adopt which path they prefer to enforce and to ensure they > have the tools and knowledge at hand to support it. > > Anyone know if Tom and Bruce know each other well enough to sign each > other's keys outright, via phone, via phone and snail-mail? That would > put us off to an excellent start. > > > Regards, > > -- > Greg Copeland <greg@copelandconsulting.net> > Copeland Computer Consulting > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, 11 Feb 2003, Bruce Momjian wrote: > > I hate to poo-poo this, but this "web of trust" sounds more like a "web > of confusion". I liked the idea of mentioning the MD5 in the email > announcement. It doesn't require much extra work, and doesn't require a > 'web of %$*&" to be set up to check things. Yea, it isn't as secure as > going through the motions, but if someone breaks into that FTP server > and changes the tarball and MD5 file, we have much bigger problems than > someone modifying the tarballs; our CVS is on that machine too. Its so rare that it happens, but I do agree with Bruce :) Justin, one thought ... storing the MD5s in the database for the postgresql.org site, so that ppl can compare the two places? We'd *really* have to be compromised for that to fail, but adding the md5s would be easy enough ...
On Tue, 2003-02-11 at 20:17, Bruce Momjian wrote: > I hate to poo-poo this, but this "web of trust" sounds more like a "web > of confusion". I liked the idea of mentioning the MD5 in the email > announcement. It doesn't require much extra work, and doesn't require a > 'web of %$*&" to be set up to check things. Yea, it isn't as secure as > going through the motions, but if someone breaks into that FTP server > and changes the tarball and MD5 file, we have much bigger problems than > someone modifying the tarballs; our CVS is on that machine too. > > --------------------------------------------------------------------------- > > Greg Copeland wrote: > > On Tue, 2003-02-11 at 18:27, Curt Sampson wrote: > > > On Wed, 11 Feb 2003, Greg Copeland wrote: > > > > > > > On Wed, 2003-02-05 at 18:53, Curt Sampson wrote: > > > > > > > > [Re: everybody sharing a single key] > > > > > > > > This issue doesn't change regardless of the mechanism you pick. Anyone > > > > that is signing a key must take reasonable measures to ensure the > > > > protection of their key. > > > > > > Right. Which is why you really want to use separate keys: you can determine > > > who compromised a key if it is compromised, and you can revoke one without > > > having to revoke all of them. > > > > > > Which pretty much inevitably leads you to just having the developers use > > > their own personal keys to sign the release. > > > > > > > Basically, you are saying: > > > > You trust a core developer > > > > You trust they can protect their keys > > > > You trust they can properly distribute their trust > > > > You don't trust a core developer with a key > > > > > > Not at all. I trust core developers with keys, but I see no reason to > > > weaken the entire system by sharing keys when it's not necessary. Having > > > each developer sign the release with his own personal key solves every > > > problem you've brought up. > > > > > > cjs > > > > You need to keep in mind, I've not been advocating, rather, clarifying. > > The point being, having a shared key between trusted core developers is > > hardly an additional risk. After all, either they can be trusted or > > they can't. > > > > At this point, I think we both understand where the other stands. > > Either we agree or agree to disagree. The next step is for the > > developers to adopt which path they prefer to enforce and to ensure they > > have the tools and knowledge at hand to support it. > > > > Anyone know if Tom and Bruce know each other well enough to sign each > > other's keys outright, via phone, via phone and snail-mail? That would > > put us off to an excellent start. > > > Bruce, Since you just got back in town I'm not sure if you've been able to follow the thread or not. Just the same, I wanted to remind you that using MD5 is not a security mechanism of any worth. As such, this thread was an effort to add a layer of authenticity. Again, this is not something that MD5 is going to provide for, now or in the future. If it sounds confusing, it's only because you've never done it. Honestly, once you take the 20-minutes to do it the first time, you'll understand what's going on. Beyond that, you won't have to sign additional keys until you can validate them or as they expire. It only takes minutes once you understand what's going on after that. The time to actually sign packages is more or less the same as creating your hashes. Lastly, don't forget that your site is mirrored all over the place. As such, you're not the only place open to attack. Just because you have additional software running on this box is no reason to throw your hands in the air and say, "I don't care." Simple fact is, it only takes one site to become compromised to significantly effect PostgreSQL's reputation. And that site doesn't have to be yours. If it's an official mirror, it reflects (oh...a pun!) accordingly on the project. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting