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