ok lets move past the what if. or could be. I have read most of the
threads since the inception. Who is the moderator or top level person for
security for gentoo. Have they posted or addressed this on this thread or
in general? that part I was unable to find?
I dont mean to simplify or over complicate the matter. But is there a
legitamate solution or proposal on the table. I have read some great
ideas, and some very dis-heartening ones as well. Like most of you I
love gentoo, I love the concept behind it. So now lets move toward a
solution. There will be flaws with any of these ideas, but there has to
be a solution that will be a bit more secure and resolve some of the issue
at hand. wether that is PGP or .jar or DSA keys.
----- Original Message -----
From: "Andrew Jaquith" <ajaquith@...>
Cc: "Peter Simons" <simons@...>
Sent: Monday, November 08, 2004 8:19 AM
Subject: *****SPAM***** Re: [gentoo-security] Re: Let's blow the whistle
> I've lost track on where we are on this thread.
> That said -- there is a perfectly good standard for signing and
> verifying files in large-scale collections of code. It's called a
> signed JAR file. The 'jarsigner -verify my.jar' command works very
> The file format itself is ZIP rather than tar or gzip.
> Peter -- I appreciate your efforts to raise the visibility of this
> Andrew Jaquith
> Senior Project Manager
> Symantec Professional Services
> 196 Broadway
> Cambridge, MA 02139
> Direct: 617.768.2711
> Mobile: 617.501.3278
> Fax: 617.621.1478
> Email: ajaquith@...
> PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546
> On Nov 8, 2004, at 10:02 AM, Peter Simons wrote:
> > Brian G Peterson writes:
> >> I assume that you intend to 'blow the whistle' because
> >> you are incapable or unwilling to submit a patch for the
> >> issue yourself?
> > If you read the recent messages carefully, you'll find that
> > I have tried _numerous_ times to provide details how to
> > remedy the situation.
> >> I agree that there is a lot of room for improvement in
> >> the portage security system.
> > Then why don't we stop discussing what I know or don't know,
> > do or won't do, and talk about a solution? The vast majority
> > of text posted in this thread is concerned with all kinds of
> > things BUT finding a good, technical solution to a
> > vulnerability that _does_ exist.
> > Generating a signed hash list of all files is really not
> > that difficult. It would solve the problem in a matter of
> > hours for those who are concerned about it, and it would
> > probably set things in motion for a better solution to be
> > developed that solves the problem for all users as well as
> > possible.
> > So why is the Gentoo team so incredibly reluctant to do
> > anything about it?
> > Again:
> > (1) Configure your main site to update the portage tree
> > from CVS in a time interval that's sufficient large to
> > allow for the hash list to be generated. Someone else
> > already suggested once an hour. I can't say what is
> > appropriate since I don't know your setup.
> > (2) Calculate hashes for all files in the /usr/portage
> > hierarchy. One could probably use a trivial Makefile to
> > generate hashes incrementally, even, to ease the load
> > on the machine.
> > (3) Sign the hash file with a GPG key. That means that
> > either someone has to enter the pass phrase manually,
> > or you'll have to set up a pass phrase agent, or you'll
> > have to use a key without a password at all.
> > Everything but the first solution is sub-optimal but
> > still a _lot_ better than what we have now. If someone
> > manages to compromise the main site, we all have far
> > greater problems than a lost secret key, so even _if_
> > the pass phrase is empty we still gain security.
> > (4) Distribute the signed hash file with the portage tree.
> > (5) Provide scripts that verify the integrity of the tree
> > after an emerge sync _before_ any other code is run
> > that has been obtained from the network.
> > (6) Make the matching public key available on the key
> > servers, on the web site, and every other place that
> > you can think about. Give an expiry date of, say 3
> > months to make clear that this is an intermediate
> > solution that will change.
> > (7) Get as many people to sign the key as possible to
> > properly authenticate it.
> > (8) Write a security advisory that educates the users about
> > the problem.
> > Peter
> > --
> > email@example.com mailing list
> firstname.lastname@example.org mailing list
email@example.com mailing list