Re: [HACKERS] PGP signing releases

2003-02-11 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting

On Mon, 2003-02-10 at 21:57, [EMAIL PROTECTED] 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  [EMAIL PROTECTED]
 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 [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly



---(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 releases

2003-02-11 Thread Greg Copeland
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 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

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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(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 releases

2003-02-10 Thread greg

-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  [EMAIL PROTECTED]
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 [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] PGP signing releases

2003-02-10 Thread Peter Eisentraut
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   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-07 Thread greg

-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) [EMAIL PROTECTED]

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 [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200302071451

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

iD8DBQE+RBJovJuQZxSWSsgRAh3XAJ47eL56YmSKXJCtdAsyYzByMi+m2QCcCNjm
b1tQyp1zLxkpGjhUer6FpZQ=
=Hfpu
-END PGP SIGNATURE-



---(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 releases

2003-02-06 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-05 Thread Curt Sampson
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  [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 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] PGP signing releases

2003-02-05 Thread Bruno Wolff III
On Wed, Feb 05, 2003 at 15:22:12 +0900,
  Curt Sampson [EMAIL PROTECTED] 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.

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-05 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] PGP signing releases

2003-02-05 Thread Kurt Roeckx
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


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-05 Thread Curt Sampson
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  [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 4: Don't 'kill -9' the postmaster



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Bruno Wolff III
On Mon, Feb 03, 2003 at 22:55:12 -0600,
  Greg Copeland [EMAIL PROTECTED] 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.

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] PGP signing releases

2003-02-04 Thread greg

-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 [EMAIL PROTECTED]
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-



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Kurt Roeckx
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


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Rod Taylor
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 [EMAIL PROTECTED]

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



signature.asc
Description: This is a digitally signed message part


Re: [HACKERS] PGP signing releases

2003-02-04 Thread Steve Crawford
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/239238mode=threadtid=122tid=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, [EMAIL PROTECTED] 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.

---(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 releases

2003-02-04 Thread Greg Copeland
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/239238mode=threadtid=122tid=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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Kurt Roeckx
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


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Curt Sampson
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  [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 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Curt Sampson
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  [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 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(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 releases

2003-02-04 Thread Curt Sampson
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  [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]



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Andrew Dunstan

- Original Message -
From: Kurt Roeckx [EMAIL PROTECTED]

 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


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] PGP signing releases

2003-02-04 Thread Bruno Wolff III
On Tue, Feb 04, 2003 at 23:13:47 +0100,
  Kurt Roeckx [EMAIL PROTECTED] 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.

---(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 releases

2003-02-03 Thread greg

-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 [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200302030948
-BEGIN PGP SIGNATURE-
Comment: http://www.gtsm.com/pgp.html

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



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] PGP signing releases

2003-02-03 Thread Neil Conway
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 [EMAIL PROTECTED] || PGP Key ID: DB3C29FC




---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-03 Thread Rod Taylor
 (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 [EMAIL PROTECTED]

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



signature.asc
Description: This is a digitally signed message part


Re: [HACKERS] PGP signing releases

2003-02-03 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] PGP signing releases

2003-02-03 Thread Kurt Roeckx
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


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] PGP signing releases

2003-02-03 Thread Curt Sampson
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  [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 4: Don't 'kill -9' the postmaster



Re: [HACKERS] PGP signing releases

2003-02-03 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-03 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] PGP signing releases

2003-02-03 Thread Curt Sampson
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  [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 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 releases

2003-02-03 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-02 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] PGP signing releases

2003-02-02 Thread Greg Copeland
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 [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] PGP signing releases

2003-02-02 Thread Marc G. Fournier
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 ...


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] PGP signing releases

2003-02-02 Thread Lamar Owen
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


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] PGP signing releases

2003-02-02 Thread Tom Lane
Marc G. Fournier [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])