Just to clarify the build process that goes on here:
1) make a clean chroot (mkarchroot - only needs done once)
2) build package in chroot (makechrootpkg)
3) upload package to staging area and commit to svn (e.g. testingpkg)
4) release package on master server adding it to repo (e.g. db-testing)
Note, no remote build server....
The current code allows:
- Signing a package at the end of a build
- Adding the package signature to the repo-db
- pacman checking that signature
The question remains if/how to signing the repo db.
Options:
- do not sign the repo-db
- sign the repo-db with a key kept on the remote server
- transfer the repo-db locally and sign the reupload (alternatively,
sign a hash).
Why exactly is the repo-db needing signed? There is a risk that a
mirror could keep updating except for select packages that have
exploitable vulnerabilities in them. That would be prevented by repo
signing as the mirror would have to update all packages or none. The
argument that anybody could just add or replace packages is incorrect as
there either would not be a signed package added or it would be signed
with a non-trusted signature. I believe there is an option for pacman
to enforce package signing for a given repo so I do not see the risk there.
Signing directly on the remote server is also probably not the best
idea. We know our server has been attacked in the past, so leaving the
key to sign the repo database on there is stupid...
The repo db sizes are small so transfering them to be signed, and
transfering the signature back should be relatively quick. Even quicker
once we can convert them to .xz compression (patch already available the
release after next). I think that could be implemented by moving the
package release (step 4 above) to occur on the developers local machine
rather than on the remote server as that would require ssh access only
from the developers machine to the master server and not the other way
around. That seems more in the realm of devtools/dbscripts requiring
changes that makepkg/pacman.
Allan