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
