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

[Linas]

>  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
quite
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 
http://mail.yahoo.com