Re: [gentoo-dev] 2004.1 will not include a secure portage.

[Jesse Nelson]

* Paul de Vrieze (pauldv@g.o) wrote:
> Date: Wed, 24 Mar 2004 15:07:06 +0100
> From: Paul de Vrieze <pauldv@g.o>
> To: gentoo-dev@l.g.o
> User-Agent: KMail/1.6.1
> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
> Subject: Re: [gentoo-dev] 2004.1 will not include a secure portage.
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 24 March 2004 14:47, Jesse Nelson wrote:
> >
> >  not bout stopping intrusion just that its a verry likely poisioning
> > scenario, and even if the signing key dies after 1 day.. if i got root
> > on the server i just update. besides now theres 1 days worth of sync's
> > out in the wild with compromised builds/pataches/binaries.
>
> What I want to say is that it is more likely that the compromised time
> will be longer anyway so the (on average) 1/2 day extra doesn't matter
> that much.

signing @ a file level (even using signed sig files) stops a compromise of a rsync server from being an issue at all. imho a better solution. It does push the problem out to the devs keys or whatever you do for keys.. thats where the peer review and multiple sigs come into play. 

>
> > > There is no way to stop this before that person is identified in any
> > > case. After this person is identified his keys will be revoked and
> > > all the packages signed by him/her are invalid. They will need to be
> > > resigned by someone else to be valid again.
> >
> > you can stop this buy:
> >   having multiple eyes have to see the changes b4 a commit to rysnc
> > servers, and it follows that you would then have multiple sigs for a
> > item (build/dist/patch) etc or multiple sigs on a sums file.

100% is totally impracticall but this does double the effort required to compromise integrity. thats not that bad of an optimization really.

>
> It would only change the case so that 2 dev's private keys need to be
> compromised. It makes it more secure but not 100% secure. I think that
> 100% secure is an illusion that we should not shoot for initially.
> Multiple signing while an improvement will increase security, but first
> get single signing in place and then do multiple signing. Single signing
> will be hard enough.
>
> > this could also go through a security review b4 goin out live. Instead
> > of say relying on ppl cross-checking. A defined security team could
> > have to sign b4 release, but i doubt eaither of these would go over
> > well with already overloaded devs.
>
> We don't have such a QA/security team and would need serious
> reorganization to implement such a system. This makes it practically
> impossible to implement within 6 months.
>
> > its a QA issue.. its really a process issue.. building QA/security
> > into the release cycle.
>
> Yes, it is. However with over 200 developers changing things overnight is
> like trying to change the direction of a mammuth oil tanker 90 degrees
> in 15 minutes. It is plain impossible.

i totally agree, but im laying out my voice.. 1 sig and 1 signer is really quite easy to get around. 2 is alot harder.. and once you have the process in place for 2 sigs its is not difficult to extend it to 1+X sigs. where each itteratin of X increase trust in package quite alot. 

>
> Paul
>
> ps. hint: things need to go by small nudges and lots of patience
>
> - --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@g.o
> Homepage: http://www.devrieze.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAYZYKbKx5DBjWFdsRAvh4AJ4iLd2Dq1XVBmBontufwfGWRahf8wCfdKqj
> 4Q0LtAnDGBxEeyja29vir4A=
> =pkvN
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev@g.o mailing list
>
>

--
gentoo-dev@g.o mailing list