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

Dan McGee dpmcgee at gmail.com
Wed Dec 3 20:40:59 EST 2008


On Mon, Dec 1, 2008 at 11:06 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Sat, Nov 29, 2008 at 7:48 AM, Pierre Schmitz <pierre at archlinux.de> wrote:
>> Hi all,
>>
>> at first: it is really great that the number of mirrors is increasing and I
>> am really thankfull to those who provide one.
>>
>> The point why I feel more and more uncomfortable is that we have no way to
>> ensure tat one will get the same file from a mirror as from archlinux.org.
>> A mirror owner might be a "bad" person himself, his servers might have weak
>> security, the government of their home country cannot be trusted, they
>> might sync from another "bad" mirror. etc...
>>
>> Of course since several years demand package signing. I have even seen some
>> first code, but nothing was ever finished. It should be clear that
>> something has to be done. Manipulating packages is just too easy.
>>
>> The simplest solution would be if we sign the db files (automatically) on
>> gerolde. Of course this is less secure than signing every single package by
>> its packager; but on the other side it would be easy to implement and there
>> would be no overhead for packagers. I am aware that this method would only
>> ensure that packages on a mirror are the same as on gerolde; if our server
>> gets "hacked" we would have lost. But this should be fine and is far more
>> better than just nothing and hoping that there are no "bad guys" out there.
>>
>> Gerhard has written a small patch as a proof of concept. Ignore the details
>> at this point. The idea is as follows:
>> 1) patch repo-add in order to create a .sig file everytime the db file will
>> be changed. For this a private key readable by every dev or just sudo can
>> be used
>> 2) use this version of repo-add on gerolde. So we'll have the sinatures
>> propagated to our mirrors.
>> 3) For testing the whole thing one could just write a small download script
>> which checks the signatures of db files. (Abusing the XferCommand statement
>> in pacman.conf)
>> 4) If all went well we could think about a build-in check in pacman itself.
>> (we might be able to reuse some code here that was written for package
>> signing)
>> 5) Enable those checks by default for all official repos
>> 6) The public key should not be in a package but people have to get it from
>> our website.
>>
>> What do you think about this? Step 1 to 3 could be implemented in a rather
>> short time.
>>
>> Pierre
>
> There's too much talk on this idea. Before we go ahead and do this,
> could someone submit this patch to the pacman-dev list, so the pacman
> developers can give it a once-over. Just make sure to let them know
> that this is a temporary solution.
>
> Additionally - where will gpg get the key from on gerolde? Shouldn't
> this be configurable, or even set via an optarg to the -s param?

Yee ha! This one got a bit crazy, didn't it? I decided to let it
simmer here until it calmed down enough that my thoughts wouldn't get
lost in the mix.

First off- stop talking. Start coding. So far, Gerhard has stepped up
to the plate on this thread (thanks!), and Geoffroy Carrier has
stepped up in the past to start the ball rolling. I'm sick of all this
"we need to do this" and not a single person following through with
it.

Geoffroy Carrier made the biggest push yet in the right direction.
This is the best solution I see to this problem and is the one I am
willing to put some effort behind. As a matter of fact, we have put
effort behind it:
http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=shortlog;h=refs/heads/gpg

So what is the idea here? Signed *packages*. Why?

1. They are super easy to either leave detached from the package, or
integrate right into package databases. This work is already done:
Add GPG signature support to makepkg -
http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=0bf6375e31ac70013343bb5c1a5b8309c3d03f4f
Add PGPSIG field in repo-add -
http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=7e86019e35231ce5aed9ba7ce7ca4b5865baee68
2. Signed packages mean I, as an Arch developer, do not have to sign
off on Aaron's or Paul's or Dale's work. I sign off on my *own* work.
When Paul (sorry Paul!) decides to go rogue, we drop his signature
from the "accepted" keyring (or alternatively, revoke some signature
on his key or something) that makes his key no longer a valid signing
key for official Arch packages. We can still trust all the other
packages in the repositories.
3. Signing databases still makes md5sums a weak point, for all those
worried about that. Signing packages mean we don't even have to touch
the md5sum stuff, which is great from the pacman perspective.
(Remember: the purpose of md5sums is a download sanity check, not a
security check.)
4. Joe user can sign individual packages if he wants, and we have a
framework in place to honor those signatures and verify them.

So where do we stand on all of this? As I showed above, the makepkg
and repo-add pieces are pretty much in place. We've done a decent
amount of work on the libalpm/pacman side of things, but it isn't
complete yet and is very rough around the edges. This is something
that is very doable if people want to jump in and help us get this
done. Obviously knowledge of C would be helpful, but we can always use
some beta testers to help us work out kinks if necessary.

This feature request (http://bugs.archlinux.org/task/5331) is quite
out of date, but we can use it to start tracking things dealing with
signed packages. There have also been numerous discussions on the
pacman-dev ML about this stuff (Notably in June,
http://archlinux.org/pipermail/pacman-dev/2008-June/thread.html).

So who is willing to help? If we can get this done, pacman 3.3 can go
out the door with signing support as soon as this is done.

-Dan


More information about the arch-dev-public mailing list