On Fri, May 7, 2010 at 7:37 PM, Linas <linas_fi@ymail.com> wrote: Hi, At first, I was tempted to agree with you in almost all your points. But after a little moment to grasp them, I would like to put the following:
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 think so. Maybe the idea was not well explained. In the repository there'll be a set of signed and a set of unsigned packages. We can't guarantee anything for the unsigned ones. For the signed, we know that the current repo.db is signed (not counting the first time) and contains the versions of the packages (along with the information if a package is signed or not - it is important to avoid the user fooling pacman). So, the script will copy the new signed packages from the staging dir to the repository and update the repo.db, changing only the information about the new ones. This will be made on a temporary file (probably with mktemp to make it unpredictable - I don't know the script). The hash is computed on the temporary repo.db and sent through a secure channel (ssh), signed locally and resent through ssh again. Just after that, the temporary files are moved to the final place. I can't see how a mailcious user could cause harm on the signed packages and on the signed repo.db. Again, the first time will be more sensitive, but maybe it could be handled manually to avoid the risk and the next time it would be as described before. But maybe I'm missing something.
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.
The point about the old install media is strong, the others not so much. If you have a personal repository, you can choose not to sign the repo.db or you can have your own trusted keys. But for the official repositories, I think is valid we have a signed metadata file.
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.
Yes, but a replay attack is made with packages that have known vulnerabilities. Probably all packages we are using now have hidden vulnerabilities but that is not the case of using just the old trusted ones (or we could become Debian :).
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.
Yes, but going through all this trouble just to sign packages is a half baked solution. If we're going to do it, we should do it all. I was reading the link sent by Dan more throughly today and most of the attacks can be solved just by using signed metadata. And the others can be solved by using metadata with an expiration date, which we're aiming to do too. Thanks for the time to answer and keep it coming. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------