From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12958 invoked from network); 8 Nov 2004 02:17:28 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 8 Nov 2004 02:17:28 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CQz60-0005e9-Jk for arch-gentoo-security@lists.gentoo.org; Mon, 08 Nov 2004 02:17:28 +0000 Received: (qmail 4346 invoked by uid 89); 8 Nov 2004 02:17:06 +0000 Mailing-List: contact gentoo-security-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-security@gentoo.org Received: (qmail 16792 invoked from network); 8 Nov 2004 02:17:05 +0000 Message-ID: <418ED720.5080509@orbdesigns.com> Date: Sun, 07 Nov 2004 21:17:04 -0500 From: Brian Bilbrey Reply-To: bilbrey@orbdesigns.com Organization: Orb Designs User-Agent: Mozilla Thunderbird 0.8 (X11/20041021) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-security@lists.gentoo.org References: <418D310B.6050106@ahsoftware.de> <87sm7lvm17.fsf@peti.cryp.to> <20041107154046.GG10927@mail.lieber.org> <20041107120135.C9045@netdirect.ca> <20041107232655.GN10927@mail.lieber.org> <87zn1tqks5.fsf_-_@peti.cryp.to> In-Reply-To: <87zn1tqks5.fsf_-_@peti.cryp.to> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-security] No, apparently not. X-Archives-Salt: 236d46f5-cfa5-4feb-b1e2-fb1637bff377 X-Archives-Hash: 0984ab95b81090a1c223f63391beb572 Peter Simons wrote: > So if you guys would like to be the laughing stock of the > free software community once this vulnerability is exploited > for the first time, all I say is: Be my guest. How is this NOT a problem with every distribution that offers downloads ... oh, that's right ... ALL of them? Yep. Instead of a bunch of hounds baying at the Gentoo devs, who do what they do without much in the way of remuneration, and who have absolutely the best intentions and concern for the user base ... why not HELP them design a tool that can help ameliorate the risk to some acceptable level. I'll agree that having signed files will be a step forward in security, but also ack that in the larger scheme of things, it means little. But progress in a forward direction is always a good thing. Now, how about an independent signature/hash of the entire portage tree? If I wanted something like that, I might start with some assumptions (any of which may be false, but I'm using the assumptions to generate a scenario): 1. The master machine (or cluster or whatever) is the source of distribution to a limited set of secondary mirrors, from which all other mirrors sync, and from those, end users sync. 2. So an end user is perhaps two, but likely three steps away from the master. 3. The secondaries sync to the master on a known schedule ... let's say hourly. 4. Commits to the master currently happen on no set schedule. Okay, with those four assumptions, could we do something like this: 1. Queue up commits to the master for 55 minutes of every hour. 2. At minute 55, close off access by the secondary mirrors. 3. Apply the commits to the master. 4. Write a datestamp/serial number into the master, then run a hash against it. Put that hash on the gentoo main site, and other places where the portage tree is not mirrored, either appended to the hashfile (as a serial number / hash pair) or as a standalone hash in a file that's named for the serial number, in a directory full of such things. For example: export FILENAME=`date | md5sum | cut -f1 -d' '` echo $FILENAME >> /usr/portage/serial_number tar cf - /usr/portage --exclude distfiles | md5sum \ >> /root/$FILENAME [copy the /root/$FILENAME over to the appropriate distribution points, webservers, whatever] 5. Reopen access by the secondaries. Then, at the user end, after performing an emerge sync, the process is run again, by portage: export FILENAME=`cat /usr/portage/serial_number` wget http://www.gentoo.org/$FILENAME # thus retrieving the checksum for that particular # snapshot tar cf - /usr/portage --exclude distfiles | md5sum | \ diff - $FILENAME If the checksums match, the diff returns 0, clean tree, and we can all start worrying about the packages that are downloaded from the URLS contained in each ebuild. To break this, the main mirror can be compromised (one must presume that this is protected) OR a secondary or tertiary mirror can be owned, along with at least one source of the checksum file, which are independent of all mirror machines. Of course, the combinations of mirror and checksum sources mean that alarm bells will be going off pretty quickly, unless the main mirror is owned. Then all bets are off, but eventually we all die, right? Okay, that's one scenario, based upon possibly silly assumptions. But it or something like it could be implemented. I could probably even pretend to be able to help with a portage patch, except that I have no concept of the actual infrastructure for portage tree distribution, which will tie into how portage works with such a scheme. Let's be useful to the developers here, folks. Hell, I'm pissed off about some of what I've read in this thread, and I don't have any axe to grind in the matter. HTH, .brian -- Brian Bilbrey : http://www.orbdesigns.com/ ... maybe they can't be called "volunteers" any more if somebody ends up being silly enough to pay them for something they'd have done for free anyway. - Linus in the Seattle Times -- gentoo-security@gentoo.org mailing list