> 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
