On Sat, Nov 29, 2008 at 8:37 AM, Thomas Bächler wrote:

Gerhard Brauer schrieb:

...

For myself i don't accept the "md5sum is bad" argument as a "stopper" for each idea to provide a pacman secure concept ;-)

I wasn't going to stop you. Signed db files are an important first step.

My point is that it was often suggested to move from md5 to something more secure. This suggestion was always rejected because we never used md5 for security. If we are going to implement your suggestion (and I vote that we do), we should really consider a better hash!

I think we're confusing things here. The checksums in pacman are only used for integrity, not security. I agree that the first step towards super-omg-secure packages would be switching to a different checksum, but sha1 might be deemed insecure soon too. Why not jump over that one to something like sha256? Now, once we do that, we're still stuck with the fact that anyone with a mirror can modify a package, and change the checksum, whatever it may be, in the DB file. So changing checksums isn't doing one iota of good until we can ensure that our list of checksums can't be changed. I talked to Dan about this briefly the other day. What we concluded was that the most proper and secure way to do this is as follows: * gerolde hosts a "developer keyring" * developers sign their individual packages with their own keys * the database file still contains the integrity checksums * the database file also includes package signing data The current proposition, with one key on gerolde used to sign the DB, is insecure in that it makes the developers the weak point. If all of gerolde, or even only those with sudo rights, can see this private key, all it takes is maliciousness on one person's part and all our packages are vulnerable. The whole point of a private key is just that - that it's private. If we suddenly make this key "semi-public", we open the door to lots of other issues, at the human level. When I last spoke to Dan, the biggest issue here was that gpg doesn't have a library interface. We'd have to call the binary directly from pacman. If we look at the above solution, we can leverage the XferCommand to cover this, without affecting pacman at all: * Create a download script that will download a package, check the integrity checksum, and verify the signature in the database using the archlinux.org keyring * Pacman will continue to work as is, considering the checksum is still in the DB All we'd need is to patch repo-add to include signature data in the DB. To do this properly, signatures should be uploaded with the package itself, from the packager's machine... hmmm

Am Sun, 30 Nov 2008 01:20:13 +0100 schrieb Gerhard Brauer :

Am Sat, 29 Nov 2008 17:24:19 -0600 schrieb "Aaron Griffin" :

...

All we'd need is to patch repo-add to include signature data in the DB. To do this properly, signatures should be uploaded with the package itself, from the packager's machine... hmmm

In the starting mail on arch-dev-public Pierre attached a quick patch and download script that i have tested with my own repo. This is working in this way that a whatever modified database file don't get installed as new data during -Syu when the signature could not be verified. No new database -> no new packages.

I think i misunderstood Aaron part. He mentioned that repo-add should also add the "signature data" to the db. Maybe we don't need special data to verify a package against a valid signature. We could sign a package inline, that means the tar.gz is enveloped by a signature (default --sign option). After/during verifying the tar.gz could be seperated from the signature with --output. The disadvantage with this methode is maybe that the package archiv could not be used directly without verifying it. On the other side we sign with --detach-sign which provides a .sig File releated to the signed pkg.tar.gz. Upload (and pacman download) then must handle two files. Database signature entries: Maybe we could use existing fields to get the proper key id from the public keyring to verify. Email oder packager data. But this could be only done when package is always and only signed by it's maintainer - and AFAIK we have situations where one developer build packages for a other. So you're right: the key id oder fingerprint of the actually developer/packager/signer must be store in the database file to get the proper key id. Regards Gerhard

Am So, 30.11.2008, 00:24, schrieb Aaron Griffin:

All we'd need is to patch repo-add to include signature data in the DB. To do this properly, signatures should be uploaded with the package itself, from the packager's machine... hmmm

perhaps i missed something, but wouldn´t be the easiest way to download the db.tar.gz directly from ftp.archlinux.org or another trusted server and the packages from the mirrors? something like a decentralized system. vlad

On Sun, 2008-11-30 at 04:22 +0100, vla@uni-bonn.de wrote:

Am So, 30.11.2008, 00:24, schrieb Aaron Griffin:

...

All we'd need is to patch repo-add to include signature data in the DB. To do this properly, signatures should be uploaded with the package itself, from the packager's machine... hmmm

perhaps i missed something, but wouldn´t be the easiest way to download the db.tar.gz directly from ftp.archlinux.org or another trusted server and the packages from the mirrors? something like a decentralized system.

I think ftp.archlinux.org can be pretty slow sometimes (compared to near-by mirrors), so wouldn't it be equally sufficient to just fetch the DB-checksum from archlinux.org? (Still not as secure as signed DBs though.)

hi all, On Sun, Nov 30, 2008 at 12:54:34PM +0100, Timm Preetz wrote:

I think ftp.archlinux.org can be pretty slow sometimes (compared to near-by mirrors), so wouldn't it be equally sufficient to just fetch the DB-checksum from archlinux.org?

(Still not as secure as signed DBs though.)

the db.tar.gz file is pretty small. the extra.db.tar.gz file is about 400kb. ok, it is also possible to ge only the db checksum, but the idea is that the db file itself should be in a trusted place. with 2-3 "trusted servers" users can choose a server in a near location (.org, .de or .fr for example). On Sun, Nov 30, 2008 at 01:40:07PM +0100, Gerhard Brauer wrote:

Am Sun, 30 Nov 2008 12:54:34 +0100 schrieb Timm Preetz :

...

I think ftp.archlinux.org can be pretty slow sometimes (compared to near-by mirrors), so wouldn't it be equally sufficient to just fetch the DB-checksum from archlinux.org?

This is not possible cause mirrors sync times are different, so the result was: newer package versions in the db - but the package file is not available on users mirror. (I've had make the same request earlier in a bugtracker thread, without thinking a bit deeper... ;-)

Regards Gerhard

yes, i also thought about that. that's why i suggested to establish a db file repository with a file retention of some days (mirrors ususally sync every 2h-24h). the new db.tar.gz now looks like -.db.tar.gz and the mirror fetches the latest db file from this repository when sync'ing. pacman checks the time (name) of the db file on the mirror and fetches this file from db file repo of a "trusted server". i don't think this is hard to implement. it's only a file name and md5sum comparison. imo it's the easiest way to do this. it's easier and less work than to sign packages or similar. as a byproduct one can keep track of existing mirrors and users can directly see if mirrors they use are trustworthy or not. just my 2 cents. vlad

Aaron Griffin schrieb:

When I last spoke to Dan, the biggest issue here was that gpg doesn't have a library interface. We'd have to call the binary directly from pacman.

1) There is gpgme! But what does it do? It calls the gpg command line tool (iirc). 2) So what? Let's use gnutls or openssl. We could create an arch root certificate and sign the developers' keys with it, and use RSA or (my preference) DSA signatures. Then you can do it all on a library level.

On Sun, Nov 30, 2008 at 06:56, solsTiCe d'Hiver wrote:

i like the original idea of pierre. i had the same one ;-)

because it's easier to implement and could be done quite quickly. it's quite time to shift to something a little more secure, even if it's not the *most* secure one. as soon the db is signed, we have a minimum security (not total i know, i read about the exploit in this thread)

package signing could be a second step as it will take even longer to complete (more work to be done in pacman and more things to agree upon)

in fact, i suggest a two steps approach.

I agree. We can talk until we're blue in the face about the "ideal" way to do it, but it doesn't mean a thing if it's not implemented. Let's get *something* done, even if it's not ideal.