Arch Linux

After discussion on IRC, I don't think this attack vector exists if repo databases are signed. We confirm package name and versions match what is in the repo before signing them.

Just depending on the name and version isn't good enough. It weakens security in a way I don't feel is justified. If at any time an attacker can get a validly signed pkgname-fullver, they can silently replace packages without modifying the db.

- Evil maid attacks might temporarily get access to a trusted PGP key, but not access to the upload server. Bulk-sign bad packages, then attack user mirrors. Optionally, bulk-sign packages matching predicted future package versions to continue attacking after rebuilds/updates

- A trusted mirror might provide only databases but not packages with pacman doing failover to the second mirror, or a distribution might directly serve databases but load balance packages across a mirror network. Rogue packagers in control of a mirror can perform targeted attacks against specific users without leaving audit traces on the master repository server.

- Packages built and signed by third parties added to pacman.conf but ranked below distro repos can arbitrarily sign and replace core packages, while the user expected they only need to vet and possibly sandbox packages being installed from [otherrepo] (e.g. eyeballing the output of VerbosePkgLists, installing with pacman --noscriptlet, pacinstall --no-hooks --no-scriptlet). They can also perform targeted attacks in the load-balanced case. (This can be solved by per-repo pinning of valid key fingerprints.)

- Packagers might upload testing packages and ask users to install them with pacman -U, then after it turns out to be broken, rebuild without bumping pkgrel and ask users to install once again with pacman -U, then directly move the second attempt to the official repos. Attackers can now feed people broken packages that crash the system.

One possible enhancement of pacman would be allowing keys that are only trusted to sign the database, and/or the only key trusted to sign the database. This would be really nice to have in order to reduce the risk of storing dedicated private keys on a signing server, and prevent attackers with access to a package-signing key from replacing packages after the fact.

But that wouldn't help, if an attacker with access to a package-signing key could replace packages (permitted by the proposed key policy) and doesn't *need* to rebuild the database and re-sign it (not permitted by the proposed key policy without a db-signing key).

I agree with Eli that if we want to verify package integrity then a cryptographically strong hash value of the file content should be used. If a single bit of the package has changed it will affect the hash value.

pacman database already contains SHA256 for packages. We just need to enable it for detached signatures use-case.

A fix for this issue got merged master branch. Please verify it and let me know if you see any issues with it.