[arch-general] [arch-dev-public] Can we trust our mirrors?

[Aaron Griffin]

On Sat, Nov 29, 2008 at 8:37 AM, Thomas Bächler <thomas at archlinux.org> wrote:
> Gerhard Brauer schrieb:
>>
>> For myself i don't accept the "md5sum is bad" argument as a "stopper"
>> for each idea to provide a pacman secure concept ;-)
>
> I wasn't going to stop you. Signed db files are an important first step.
>
> My point is that it was often suggested to move from md5 to something more
> secure. This suggestion was always rejected because we never used md5 for
> security. If we are going to implement your suggestion (and I vote that we
> do), we should really consider a better hash!

I think we're confusing things here. The checksums in pacman are only
used for integrity, not security. I agree that the first step towards
super-omg-secure packages would be switching to a different checksum,
but sha1 might be deemed insecure soon too. Why not jump over that one
to something like sha256?

Now, once we do that, we're still stuck with the fact that anyone with
a mirror can modify a package, and change the checksum, whatever it
may be, in the DB file. So changing checksums isn't doing one iota of
good until we can ensure that our list of checksums can't be changed.

I talked to Dan about this briefly the other day. What we concluded
was that the most proper and secure way to do this is as follows:
* gerolde hosts a "developer keyring"
* developers sign their individual packages with their own keys
* the database file still contains the integrity checksums
* the database file also includes package signing data

The current proposition, with one key on gerolde used to sign the DB,
is insecure in that it makes the developers the weak point. If all of
gerolde, or even only those with sudo rights, can see this private
key, all it takes is maliciousness on one person's part and all our
packages are vulnerable.

The whole point of a private key is just that - that it's private. If
we suddenly make this key "semi-public", we open the door to lots of
other issues, at the human level.

When I last spoke to Dan, the biggest issue here was that gpg doesn't
have a library interface. We'd have to call the binary directly from
pacman. If we look at the above solution, we can leverage the
XferCommand to cover this, without affecting pacman at all:
* Create a download script that will download a package, check the
integrity checksum, and verify the signature in the database using the
archlinux.org keyring
* Pacman will continue to work as is, considering the checksum is
still in the DB

All we'd need is to patch repo-add to include signature data in the
DB. To do this properly, signatures should be uploaded with the
package itself, from the packager's machine... hmmm