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
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
3. The secondaries sync to the master on a known schedule ... let's say
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.
export FILENAME=`date | md5sum | cut -f1 -d' '`
echo $FILENAME >> /usr/portage/serial_number
tar cf - /usr/portage --exclude distfiles | md5sum \
[copy the /root/$FILENAME over to the appropriate distribution points,
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`
# thus retrieving the checksum for that particular
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
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.
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
firstname.lastname@example.org mailing list