(I hope i don't triple-post this mail, sorry)
Hi,
i took this mail from arch-dev-public and arch-general discussion about
"Can we trust our mirrors"
Am Mon, 1 Dec 2008 11:06:02 -0600
schrieb "Aaron Griffin"
There's too much talk on this idea. Before we go ahead and do this, could someone submit this patch to the pacman-dev list, so the pacman developers can give it a once-over. Just make sure to let them know that this is a temporary solution.
I attach my patch to repo-add and a pacman download script to explain how things *could* be done. A proof of concept, working and tested on my local repo.
Additionally - where will gpg get the key from on gerolde? Shouldn't this be configurable, or even set via an optarg to the -s param?
In my environment the signing key is getting from my sec-keyring, cause i start repo-add under my UID. It's the default key in gpg.conf if you have more than one key. And of cource: on gpg command line the key could be selected by several criteria, also from a special keyring. Keyring or keys must kept secure of cource, so mostly the are in $HOME/.gpg This is only a concept for signing the package db for the repos. These database files are created only on gerolde (?) an should be signed only there and from the process which creates the database. This is repo-add. #Q: Which key, where does it come from, how to prevent this key(s)? I would assume only one secret key for database signing. AFAIK from Pierre repo-add is under normal procedures not called directly by the developers, only from upload/build scripts. So one solution maybe: create a dedicated user. repo-add then is running *only* under this UID. The secret key could be in the $HOME of this user, so it's secured from other access. Only god mode users on gerolde could "see" it, and maintain it (revoke, renew, etc.). In the scripts which called repo-add (or if single users must call repo-add directly) we could call it with su or sudo. Without special key selecting then the key is took from $repo-add-userid's keyring and cause it's the only keys it is automatically the default key. #Q: How to implement this in pacman on users side? In my test i use the pacman.conf option XferCommand and a special download script for. I call it like this: XferCommand = /tmp/pacsigdl %o %u Each download is checked if this is a *.db.tar,gz. If yes, the file is verified with the public key part from above. If verification is ok then pacman continues with this db file as usual, if verification failed pacman ignores the downloaded (corrupted) file and signals this for this special repo db (but continues with the rest of a -Syu). No new database for a repo -> no new packages to download/install. That way with XferCommand is not a real solution: a) It makes pacman intern downloading (libalpm) obsolete. b) Downloads for *all** packages(incl. database files) must be handled with wget or curl, which produces verbose or zero output which breaks our normal pacman output. c) The verifying part should not be delegated to the user. Ideally pacman would handle this process itself. (I'm nor a c programmer). #Q: Must we real use gpg command line? Must we use gpg? My experience with other Trust-Solutions are low. Also it seems that there are no good libraries to gpg for accessing functions from c programs. http://www.gnupg.org/related_software/libraries.en.html Thomas(brain0) mentions for ex. gnutls or openssl If we could integrate gpg (command-line or by lib) better in our framework then i think: gpg is a good, well known solution. #Q: Signing only the database is not secure! Yes, it would currently only secure our package hash/checksum functions against manipulations, not the packages itself. But IMHO it's a good starting point to get forward. Ideally we must sign the db files also when we sometimes have a super dupper package signing framework ;-) So let's start (and gain experience) fist with the db files. Currently our check-sums(md5) are only download check-sums. They could be manipulate (and therefor easily the corresponding package) on each station after the db leaves gerolde. From a secure view the checksums are useless. If we sign our db file we secure the checksums against manipulating. Not the packages itself. But package manipulating is a lot more difficult to do as in our current situation. And we could switch to a better package check summing solution than md5sum to gain more secure against package manipulation. Ideally we come some day to a framework were also the packages are signed by packagers/developers. Some days. Next step. That are my thoughts on this thing. Surely not complete. (Sorry for my not good English ;-) I attach also a tar archive with a) a repo-add patch and b) a download script for using in pacman.conf) Regards Gerhard