Hello, sorry for the late answer. so since we think that some of our points got misunderstood, we would like to clarify some aspects. On 02/08/2011 11:02 PM, Dan McGee wrote:
(4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. But not one key, and how does one verify a package they got that was not in a sync DB? Or in a sync DB managed by someone they may trust less, but packaged by someone they may trust more?
A package not in a sync DB cannot be verified - regardless of keeping the package signature in the sync db. If the sync DB is signed, the hash of the package file is sufficient to verify its integrity. The only way allowing for the verification of packages which are not part of the sync DB I can think of would be to somehow make the packages contain the signatures (like RPM packages).
If an attacker can acquire a private key of any maintainer he can generate valid signatures for every package and also for the sync db. The more maintainers there are, the more private keys are around and the bigger is the risk of a key being compromised. Sure- but I'm not quite sure why this makes a difference- if just the DB is signed, or the DB + packages, the same keys would be viewed as valid for both.
If only the DB is signed, the private key could lie encrypted on a guarded server. So instead of having multiple scattered private keys, one would suffice.
Suggestions: there are different ways to improve the situation. One possibility would be to remove the package signatures from the the sync db and only sign the sync db itself with a central repository key on the server. This is the way Debian does it. Of course this requires some kind of system where the maintainers can submit their (signed) packages. So now you've opened up another can of worms, from what I see. If the database key was compromised, every package also has to be viewed as compromised or possibly tampered with. If 100 packages are signed with ~15 different keys, even if whatever key last signed the repository is compromised, we don't have to reverify any existing packages except those signed with the compromised key.
Our point was: If an attacker gets hold of any maintainer key, he can modify arbitrary packages and re-sign them and also the sync db. This does not necessarily has to be on the main archlinux server but could also be achieved through Man-In-The-Middle attacks on a syncing mirror. The mirror could even be hosted by a malicious entity.
So yes, there is the possibility of someone trying to resign every package, but that could be seemingly prevented or at least guarded against with smart backups and snapshots.
But only on the main archlinux server. You could not prevent an attacker from hosting malicious mirrors with correct signatures. GPG key revocation solves this issue but is not that easy - revocations have to be downloaded and checked against before every update operation (during which the keys could be modified or substituted, a backdoor installed etc.).
No matter what, private keys should not be ending up on a central server (outside of maybe a repo-signing key)- that is too dangerous as you point out.
In our opinion having one key on a central, guarded server is better than having multiple keys scattered on various client machines. The key could still be protected by a passphrase and only unlocked (manually) during the signature process.
The server would then verify the signature and afterwards automatically sign the updated sync db with the repository key. Another possibility would be to keep the maintainers’ signature in the package (e.g. in the .PKGINFO file) It is impossible to sign yourself, so this is not going to work, unless I'm missing something. Even with that said, how is a detached signature any less secure, whether it be in a standalone file or base64 encoded in the sync repository?
Yes, we didn’t think about Arch’s package format when writing this. But verifying packages which are not in the sync DB would only be possible with either a detached package signature (then the user would have to download two files) or a signature that is somehow inside the package (which would require a change in Arch’s package format). The main problem is that including the package signatures in the sync db without pacman differentiating between repo- and maintainer keys makes the whole thing less secure because there are more keys around which could get compromised. What would make the whole process a lot more secure is choosing specifically the public key of the maintainer of the package (which can be obtained from the sync DB) when verifying packages.
and differentiate between maintainer keys and the repository key when verifying the signatures in pacman (i.e. separate keyrings in /etc/pacman.d/gnupg). Then the package signatures would add additional security because an attacker in possession of the central repository key could not sign the packages themselves. An attacker in possession of any maintainer key could not sign the root metadata (sync db), either. This makes a lot of sense- keeping the two sets of keys as independent verification would help, although in the case of any private repo, I would expect the same signature on both package and DB, so we would still want a way to allow for that.
Best regards, Christoph Michael