FS#54854 - multiple signatures for one package

Attached to Project: Pacman
Opened by Erich Eckner (deepthought) - Monday, 17 July 2017, 20:41 GMT
Task Type Feature Request
Category Backend/Core
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Summary and Info:

Allow multiple signatures for a single package to be handled by pacman.

Details:

Currently, a package can be signed multiple times with
> gpg --detach-sign -u uid1 -u uid2 package.pkg.tar.xz
and added to the database via
> repo-add repo.db.tar.gz package.pkg.tar.xz
as usual. However, 'pacman -S package' currently fails if one of the signing keys is not trusted.

I propose the following change to the possible values in pacman.conf for "SigLevel":
"Required:n" is introduced. "n" is some number, determining the number of signatures which are required to be valid - ignoring invalid signatures - to trust the package. Alternatively "n" can be "All", meaning that all present signatures need to be valid and that at least one signature is available.
"Required" gets deprecated and is now synonym for "Required:1" (or "Required:All" - more consistent with the current behaviour, which probably no one relies on, currently.)

This has the following two advantages:
1st long-time-packages:
A package can get a couple of signatures and as long as at least one is valid, it will be considered valid (if "Required" is specified, like the current default is).
2nd reproducible built packages:
If packages built multiple times on different machines, by different users and signed by different keys, are binary identical, they can accumulate signatures, increasing the level of trust. One could think of a "repo for paranoid" which has only packages with multiple signatures, showing that the packages have not been modified by a single person. Then, one could put into its pacman.conf 'SigLevel = Required:3 DatabaseOptional'

Let me know if you like this functionality in principle, and I'll try to figure out how to implement it and provide a patch.

Cheers,
deepthought
This task depends upon

Comment by Eli Schwartz (eschwartz) - Tuesday, 18 July 2017, 16:54 GMT
https://mirror.archlinux32.org/irc-logs/%23archlinux-ports/2017-07-17.html#21:02:20

And elaborating further... I cross-posted this to #archlinux-reproducible, and it came out that we might want to be able to specify that at least one key must be TrustedOnly, but the other n-1 keys for asserting reproducibility can be TrustAll.
This would allow adding a keyring of independent people with unknown/marginal trust who can add their signature to assert reproducibility, but aren't allowed to publish a package on their own without a Dev/TU signing off on the package as well.

Loading...