[pacman-dev] Signing the database again
Hi, I have been thinking about the DB signing feature recently, and I have dug up old emails regarding this topic. If I understand correctly: - we would like database signing to prevent an attacker from messing with the information contained in the database, being at rest on a mirror or in flight. Packages being signed protects us from most issues, but it is still possible for example to prevent a specific package from being upgraded by altering its entry in the database ; - requiring TU and devs to sign the database when publishing a package is not easy and ; - we don't want to have a package-signing key online if we can prevent it, so ideally the key used to sign the database should not be able to sign packages ; - in addition to that, it would be nice if package-signing keys would not be able to sign the database. I believe a simple solution would be to use a separate WoT for database signing, distinct from the one use for package-signing. This would require the generation of new, separate master keys for verifying db-signing only keys. The master keys would be kept offline while a db-signing key would be kept online on an official Arch server and used by repo-add to sign the database upon modifications. As I am not a TU nor a developer, I am not familiar with the exact process used to publish packages. I have discussed this a bit with Levente, but this is clearly the fuzziest part for me, so please let me know if this is non-sense. This may require the use of a set-uid or set-gid binary so that different users are allowed to use repo-add without giving them access to the db-signing key. Setting up database-signing this way, a compromised mirror couldn't alter the database or the packages without being detected. If the db-signing key were to be compromised, this would not be enough to be able to alter the content of packages, and the key could be revoked and replaced quite easily, so we would not be in a worse position than without db signing. Most of the code required for this to work is already in pacman. We would still need to patch pacman to be able to use a separate gnupg directory for the database WoT, distinct from the packages WoT. I have attached a PoC patch to illustrate this idea, but it clearly needs more work. Any thoughts?
On 04/11, Remi Gacogne wrote:
- requiring TU and devs to sign the database when publishing a package is not easy and ;
It shouldn't be particularly hard, someone just has to do the work on devtools to support it.
- we don't want to have a package-signing key online if we can prevent it,
No need to do any signing at all on the server.
so ideally the key used to sign the database should not be able to sign packages ; - in addition to that, it would be nice if package-signing keys would not be able to sign the database.
Doesn't really matter much in practice. [snip]
As I am not a TU nor a developer, I am not familiar with the exact process used to publish packages. I have discussed this a bit with Levente, but this is clearly the fuzziest part for me, so please let me know if this is non-sense.
Basically, 1) packages are built locally (preferably in a clean chroot, but there currently aren't technically any rules about it.) 2) commitpkg signs the built package (if necessary), does a svn commit of the current PKGBUILd and misc versions, runs archrelease which copies the current package's trunk to the repos branch, then commitpkg rsyncs the built package and the signature to nymeria. 3) Dev or TU SSH's to nymeria and does a /community/db-update or /packages/db-update which locks the DBs, moves the built packages to the correct location, adds them to the DBs, and then unlocks them again. IMO the simplest way to add DB signing would be to modify the 3rd step to have a local wrapper that first SSHs to the server and runs a script to lock the DBs, moves the built packages in place, adds them to the DB and then exits. Then the local wrapper script would download the DB, and sign the DB locally before uploading the DB and the new signature, then runs a second remote script that puts the DB and signature in the right place and then unlocks the DB. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On 05/11/15 07:07, Remi Gacogne wrote:
Hi,
I have been thinking about the DB signing feature recently, and I have dug up old emails regarding this topic. If I understand correctly:
- we would like database signing to prevent an attacker from messing with the information contained in the database, being at rest on a mirror or in flight. Packages being signed protects us from most issues, but it is still possible for example to prevent a specific package from being upgraded by altering its entry in the database ; - requiring TU and devs to sign the database when publishing a package is not easy and ;
Is not easy (if you don't want to force database downloads) and many would refuse - I don't know what the previous person did to the database and I would be resigning that.
- we don't want to have a package-signing key online if we can prevent it, so ideally the key used to sign the database should not be able to sign packages ; - in addition to that, it would be nice if package-signing keys would not be able to sign the database.
Package signing keys should be allowed to sign databases. Many repos already do this.
I believe a simple solution would be to use a separate WoT for database signing, distinct from the one use for package-signing. This would require the generation of new, separate master keys for verifying db-signing only keys. The master keys would be kept offline while a db-signing key would be kept online on an official Arch server and used by repo-add to sign the database upon modifications.
No. There is absolutely no need for a second web-of-trust. We made pacman use a web of trust in the first place to allow for the relatively decentralised packaging model Arch uses. Every other distribution managers to sign their databases without separate keys, and I see no reason why Arch can't. This is an Arch specific problem and nothing to do with pacman development, so should be moved from this mailing list, but... What I have proposed in the past (and was not objected to, but also had nothing done about it): 1) have a database signing machine (S) that is "cut off" from the world with a database signing key that is signed by the Arch master keys. 2) devtools on our package server (P) does not update databases, but rather puts "commands" into a machine readable file. 3) S rsyncs from P, sees if database needs updated, does so, and signs it. Then the signed databases are pushed to P.
participants (3)
-
Allan McRae
-
Johannes Löthberg
-
Remi Gacogne