[pacman-dev] [arch-general] Package signing

[Denis A. Altoé Falqueto]

On Wed, May 5, 2010 at 8:11 PM, Allan McRae <allan at 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
-------------------------------------------