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

[Denis A. Altoé Falqueto]

On Fri, May 7, 2010 at 7:37 PM, Linas <linas_fi at 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
-------------------------------------------