[pacman-dev] [arch-general] Package signing

Linas linas_fi at ymail.com
Sat May 8 00:37:05 CEST 2010

>  4. (at the server) generate a sha1 hash for the new repo.db
>  5. (locally) scp the hash to the local system
>  6. (locally) sign the hash with the developer's key. This signature
> can be an attached one, so we send both the hash and the signature on
> the same file and don't need to change other tools to much.
>  7. (locally) scp the signature back to the server
This isn't more secure than having a low trust gpg key at the server
just for
signing it. Note that the developer is blindly signing whatever the server
provides him. He would need to have a local copy of the whole repo and
locally compute the hash in order for it to be meaningful. Or have easily
updateable signatures, but the packages are already individually signed.

I don't see the need for a repo db hash (against malicious users, it can be
useful to detect a corrupt download).
Repositories with old packages are fine IMHO. I could have a "preferred
packages" repo, I could be sharing an old, working package with other
people, I may have an install media which contains an outdated repository.

Not all usages of a different than the published one have to be malicious.
They may be there to avoid a known bug in a newer release. The same
attack is even inversely possible, by using a *newer* package (which was
briefly on testing) to exploit a bug on it.

If our only concern are rogue mirrors of the main repositories, that's
easy to solve by checking their latest version on a central location,
eg. by
getting the hash of latest version from a dns record, like clamav does.
(That hash could the be shortlivedly signed to avoid dns poisoning, too)

I don't see an appropiate way of extending that when users add malicious
repositories, although in such case they probably trust the owner key and
are already sold.

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the pacman-dev mailing list