Mailing List Archive

On Thursday 11 November 2004 01:43 pm, James Dennis wrote:

> I primarily read this list for advisories and new ideas, but would
> prefer a list of ideas or methods be broken apart into something more
> readable and lacking flames and in fewer emails.

wtf did you guys think you were doing when you signed up? If you want
announcements, join the security announcement list.. This is for security
related discussion..

From the site:
gentoo-security -- For the discussion of security issues and fixes

KEY WORD DISCUSSION.. This is friggin list..

Jeff

the key word being discussion. So we have peters fix. are there any
others?

Kurt can you clarify this for me or give me more detail... on what you
mean what you say below? What is the more robust solution? I dont recall
reading it here?

"The solution that Peter is requesting (generating hashes of files not
already hashed and then signing all Manifests/hashes) is considerably more
risky and is not something I will implement since we have a more robust,
better solution in the works already."

Thanks

----- Original Message -----
From: "Jeff Smelser" <tradergt@smelser.org>
To: <gentoo-security@lists.gentoo.org>
Sent: Thursday, November 11, 2004 12:55 PM
Subject: Re: [gentoo-security] Maybe a new approach?




--
gentoo-security@gentoo.org mailing list

On Thu, Nov 11, 2004 at 01:11:15PM -0700 or thereabouts, Glen Combe wrote:
> Kurt can you clarify this for me or give me more detail... on what you
> mean what you say below? What is the more robust solution? I dont recall
> reading it here?
>
> "The solution that Peter is requesting (generating hashes of files not
> already hashed and then signing all Manifests/hashes) is considerably more
> risky and is not something I will implement since we have a more robust,
> better solution in the works already."

It's been mentioned numerous times. The strategic approach to fixing this
issue is taking the work we've already put into signed manifests and
extending it to cover other files as well (eclasses, profiles, etc.) There
is an open RFE bug for this and Jason (one of our portage devs) has already
said they're working on it.

--kurt

Kurt.

Detail of time and implemention is what I have in mind. I sense you might
have a good feel for that? Weeks? Months?

----- Original Message -----
From: "Kurt Lieber" <klieber@gentoo.org>
To: <gentoo-security@lists.gentoo.org>
Sent: Thursday, November 11, 2004 1:20 PM
Subject: Re: [gentoo-security] Maybe a new approach?




--
gentoo-security@gentoo.org mailing list

On Thu, Nov 11, 2004 at 01:31:14PM -0700 or thereabouts, Glen Combe wrote:
> Detail of time and implemention is what I have in mind. I sense you might
> have a good feel for that? Weeks? Months?

Nope, I have no sense whatsoever, so I won't even hazard a guess.

--kurt

On Thu, 11 Nov 2004 13:31:14 -0700
"Glen Combe" <gcombe@co.weber.ut.us> wrote:

> Kurt.
>
> Detail of time and implemention is what I have in mind. I sense you
> might have a good feel for that? Weeks? Months?

Well, first lets see what we're still missing implementation-wise:
1) checksums/signatures for eclasses, profiles, the "scripts" dir and
maybe a few others
2) enforcement for devs to sign their packages
3) some kind of PKI for portage signing keys
4) better verification support, the current implementation has a few
problems (performance sucks and key management is almost completely
manual)
5) stuff I forgot to mention here

So now what needs to be done to fix these points:
1) a) decide how these files are to be signed/verified (one Manifest for
all eclasses, individual signatures, ...)
b) modify repoman to work in those dirs (currently it's only for
package dirs)
2) a) ensure that *ALL* devs use repoman
b) change repoman so only signed packages/eclasses/... are committed
3) not sure
4) a) find a way to improve gpg performance
b) add support for 3)
5) no clue ;)

From this list, 1a), 2a) and 3) are outside the scope of dev-portage
(well, we could make an arbitrary decision for 1a), so I can't give any
estimates for them. I also can't give any estimate for 4a) as I don't
know if that's possible or 4b) as it depends on 3). So the only points I
can give any information on are 1b) and 2b):
1b) shouldn't be too difficult although repoman is tricky piece of
software, I'd guess it would take a week or so for an initial
implementation (depends on 1a of course)
2b) Tricky to do this in a proper way. Pretty much needs real
transaction support in repoman. A 80% solution is pretty simple though
(less than a week). I'd need to go into implementation details of
repoman to completely explain this.

Marius

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.