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

[Chris Bainbridge]

On Thursday 25 March 2004 09:39, Paul de Vrieze wrote:

> I have a number of questions:
> - - How do you know that I didn't just create a new ACL file (maybe for a
> new package) and signed it myself, and used it to give myself access to
> this package and add malicious code.

You need to be in the ACL at /usr/portage/pkg-parent-dir to create the new 
package. To update an ACL, the new ACL has to be signed by people in the old 
ACL.

> - - How do you propose all those ACL's get created. Especially as we don't
> want to limit who may commit where. In some cases it is actually
> essential that certain parties (managers) perform fast commits on a
> package they are not normally involved with.

This is a management issue. Decide who is responsible for different parts of 
the tree. If you allow everyone to commit anywhere then you are heading for 
trouble - would you give someone you only know through irc root access to 
your pc? Thats effectively what you're doing. Every new developer adds a new 
point of compromise; there have to be some restrictions.

> The current IMPLEMENTED system is even less work for developers. An
> update just requires signing the manifest. This is done automatically by
> repoman so it just means one needs to enter his passphrase (or use
> gpg-agent)

Same here, everything can be automated with scripts.

> > In this mechanism it is not necessary to sign each others keys, or
> > have a master key. Each developer is responsible for their own key.
> > OpenPGP keyservers only store the public keys. Without a developers
> > private key it would be impossible to generate a valid signature. Even
> > if the keyserver is hacked, and a rogue public key inserted, the key
> > will not match the KeyID in the ACL (the GPG keyid is a hash of the
> > public key). It is not even necessary to implement key distribution -
> > given a signature or keyId gpg can automatically fetch a public key
> > from the openpgp keyserver network and verify that it is the correct
> > one. The only attack that would work is to compromise enough gentoo
> > developers private keys so as to be able to generate the minimum
> > number of signatures for a package.
>
> This approach still relies on minimum signatures being bigger than 1.
> While that would work for ACL's this will currently not work for
> manifests. It would put alternative architectures to a grinding halt and
> seriously limit the possibilities of the x86 development.

Unpopular packages may only require one signature, but surely something that 
would compromise every user (like glibc) should require multiple signatures? 
If you really need it add a FEATURES flag to ignore signatures. Obviously 
normal users should never set it. I'm not sure why you think it wouldn't work 
for manifests; its just a file.

> Paul
>
> ps. Based on one public key on a single trusted source (A CD), how do you
> ensure that the whole tree is uncompromised.

You can't. Its an old tree which has already been signed. Trust it, or update 
to a new tree.

> pps. How do you ensure that at a compromise of a key / or a rogue
> developer this key is invalidated even when revocation is not possible
> (like with a rogue developer)

Remove the key from the ACL.

--
gentoo-dev@g.o mailing list