[pacman-dev] Signing the database again

[Allan McRae]

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.