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.