[arch-dev-public] [RFC] Moving repos to nymeria

Xyne xyne at archlinux.ca
Sun Sep 16 12:03:19 EDT 2012


Allan McRae wrote:

>What does "check it and sign it" mean?  Diff it to the old and signed
>database?

By "check it" I mean check that each signature in the database is authentic and
trusted, and that every package in the database is signed. I thought there was
an easy way to verify each signature's authenticity without also verifying the
file's integrity, i.e. confirm that foo.sig was indeed created by user x without
caring if it matches foo (pacman handles that).

Looking at the command-line options for gpg I do not see any way to do this
directly, but that information is contained in the file, e.g.

$ wget foo.sig
$ touch foo
$ gpg --verify foo.sig
gpg: Signature made ... using RSA key ID ...
gpg: BAD signature from ...

The ID and other data can also be dumped using pgpdump (pgpdump-git in AUR).

It should be possible to write a simple tool to extract the key ID from each
signature (e.g. using gpgme or a wrapper shell script). As long as each file in
the database is or appears to be signed by a trusted key, it should be secure.
Pacman will check each signature during installation. Even if the signature
ID was somehow forged, the integrity check should fail. (If valid signatures
can be forged then the whole system is useless anyway.)

This approach will obviously involve some overhead as the ID of each signature
will need to be extracted and checked, but that should not be significant
compared to the overhead of package building. The advantage that I see in this
approach versus the one below is that you do not need to maintain a chain of
trust. Each database version is verified independently. As mentioned, there is
no locking either.

>Anyway, I think it would need locked throughout.  If B updates the
>database while A is uploading, that is not different to bad guy C
>adjusting the database and leaving it for someone to sign on the next
>addition.   The only way to maintain what would be a chain of trust -
>where we can link each database update to the previous database - is to
>have the current db signature checked before adding the new packages and
>resigning.


More information about the arch-dev-public mailing list