On Wed, 3 Dec 2008 19:40:59 -0600 "Dan McGee" <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 11:06 AM, Aaron Griffin > <[EMAIL PROTECTED]> wrote: > > On Sat, Nov 29, 2008 at 7:48 AM, Pierre Schmitz > > <[EMAIL PROTECTED]> 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 This is good news, I'll gladly help beta test.
