On Wed, May 5, 2010 at 8:11 PM, Allan McRae <allan@archlinux.org> wrote:
This is the current Arch package upload procedure. Of course, it is not set in stone and if it requires changes for signing then that is fine.
1) packages are built locally, committed to SVN and uploaded to a staging directory on the main server.
I think the preferred way is building in a chroot, isn't it? To avoid having to copy the private key to the chroot environment we have three choices: 1. sign the package before uploading it to the staging area; or 2. change makechrootpkg to also sign the package, calling makepkg to do the signing; or 3. change mkarchroot to bind ~/.gnupg to the corresponding directory of the chroot Maybe 3 is the easier change, but I think it will not work for existing chroots, will it? 1 and 2 are equally efficient, so I think it's no big deal between the two.
2) on the main server, the dev runs a script that adds the packages in the dev staging area to the repos and updates the repo database. This script does some sort of locking to prevent races conditions.
The better is never export the private key. So, does the script that copies the packages runs locally or remotely? If it is remotely (with the user having to log into ssh first), it would be harder to exchange data with the local environment, where the personal keyring is. If it is run locally, we can automate the following workflow: 1. (at the server) check if the repo.db is locked. Just proceed if it is not. 2. (at the server) lock the repo.db to avoid race conditions 3. (at the server) call repo-add to update the repo.db 4. (at the server) generate a sha1 hash for the new repo.db 5. (locally) scp the hash to the local system 6. (locally) sign the hash with the developer's key. This signature can be an attached one, so we send both the hash and the signature on the same file and don't need to change other tools to much. 7. (locally) scp the signature back to the server 8. (at the server) unlock the repo.db To check the validity of the repo.db signature, we can do: 1. pacman downloads the repo.db and the signature 2. gpg extracts the original hash from the signature 3. sha1sum recomputes the hash on the downloaded repo.db 4. the recomputed hash and the signed hash are compared If the comparison is ok, the repo.db is intact. Otherwise, panic!! But this doesn't solve the problem of a replay attack (as pointed by Dan, some emails above), where an evil mirror admin puts an old validly signed repo.db to force some user to download a validly signed old package with an known vulnerability. This is tougher to solve. We would need some guaranteed way to tell if the downloaded repo.db is really the latest..... No ideas for now. Suggestions and comments, please. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------