Re: [HACKERS] PGP signing release
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 <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PGP signing release
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 ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PGP signing release
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 <[EMAIL PROTECTED]> > Copeland Computer Consulting > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PGP signing release
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 <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PGP signing release
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 <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
