Skip site navigation (1) Skip section navigation (2)

Re: New ftp layout

From: Troels Arvin <troels(at)arvin(dot)dk>
To: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: New ftp layout
Date: 2004-12-03 16:58:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On Fri, 03 Dec 2004 16:21:42 +0000, blacknoz wrote:

> Why don't you /simply/ upload your key to a keyserver?

I should and I will, some day, when I get around to it (my older keys
were also on keyservers). But I'm not very fond of keyservers; there seems
to be several, uncoordinated key server projects and it's not clear where
to go. Also: There is no way to revoke a key if you don't haven't prepared
for revocation. Yes, one _should_ prepare for revocation, but that might
not be clear to the beginner (like it wasn't clear to me when I started
using PGP), so the keyservers slowly become cluttered with useless public
keys (like my first key for which I forgot the pass phrase).

At any rate, in my opinion, people should be able to use RPM signature
verification of the files distributed by pgadmin without having to use
key-servers. Thus, it's still relevant that downloaders are somehow
instructed in how to get the needed keys for RPM verification.

> To me, gpg signing is efficient if (at least):
I find GPG signing nice and efficient even though all those requirements
might not be true. First and foremost, it lets me use ftp mirrors with
more confidence. I try to never get software from mirrors unless it's
signed. And gpg-signed files are easier to use than MD5 sums if you
already have the relevant public keys in your keyring (especially when
using RPMs which often have the signature embedded).

About the many public key distribution and verification issues: Yes, it's
complicated and in a perfect World, we would sign each others' keys after
having seen picture ID, etc., but I basically like the following property:

Case 1:

1. I import the public key of software distributor X at time
2. Distributor X's web-site and distribution channel is compromised
   at time t+1.
3. I grab an update at time t+2 and notice that something's wrong.

Case 2:

1. Distributor X has their systems compromised at time t.
2. I grab there (bogus) public key at time t+1 and
   use it to install all kinds of malware.
3. At time t+2 someone else who had grabbed distributor
   X's original, valid public key some time ago notices that something's
   wrong, and it becomes public news.
4. I can reinstall all my systems. Sucks, but at least
   I got to know.

Case 3 (the really bad one):
Distributor X is compromised for a very short time and keeps it secret. I
happen to grab their public key + software just when this happens. Noone
else notices, so it doesn't become public news. My system is rotten and I
don't know it.
Fortunately, case 3 is not very likely to happen. In the other - more
likely - cases, use of signatures is a win.

> [...]
> - your private key is protected (I mean not on a host on the net)

So whenever I use my key, I have to copy the file to work on to a floppy
disk and carry it to a host which has never been network-exposed? That
doesn't sound very security-promoting to me.

To sum up: I believe that signing of RPMs (and other types of signing) is
of high practical use, and the pgadmin project should make use of it.

Greetings from Troels Arvin, Copenhagen, Denmark

In response to


pgadmin-hackers by date

Next:From: Dave PageDate: 2004-12-03 17:15:31
Subject: Re: New ftp layout
Previous:From: Andreas PflugDate: 2004-12-03 16:39:30
Subject: Re: RFC: Update wizard

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group