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

Reply via email to