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

[Jesse Nelson]

* Paul de Vrieze (pauldv@g.o) wrote:
> - - one master key whose public key is put on every cd. It should be signed
>   by as many people as possible and also put on a ssl protected website
>   with a real certificate (payed for).
> - - a signing key. This key is signed by the master key and is rotated on a
>   regular basis (say once a month). The public key is put in the portage
>   tree.
> - - The signing key is used for signing a list of the fingerprints/public
>   keys of all developers with ebuild commit privileges.
> - - After an rsync all signatures for packages with changes are checked.
>   This will first check the signing key based on the known master key
>   (which should change as little as possible and be kept very secure).
>   It also verifies that the signing key is not too old. This is important
>   so that compromise of the signing key will be less of a security issue
>   even when it is not possible to get the revokation of the key to all
>   users.
>   Then it will verify that the list of developer keys is valid based on
>   the signing key.
>   Next it will check that the signature file for this package is correct
>   and validates that the key used for signing this signature is in the
>   list of acceptable keys.
>   If the package is found to be invalid we could start with removing the
>   package from the repository.
> - - As the checking is done post-rsync there is no problem with infrequent
>   rsync-ing.

  so a dev key would be revoked by a sync on a file containing a list of dev keys ? 
  what if i compromise a rsync server adn a developers box. This isnt that far fetched a scenario. I get acess to a dev key and i stop a server from updateing the signed key sigs file.  

this also doesnt begin to solve the rogue developer problem (tho thats not the goal on this i guess)

imho every package needs 2 pairs of eyes b4 gettin released. (2 dev sigs + sign key) but theres procedural and time constraints that will probly prevent that from ever happening. 


>
> note:
> *) alternatively there could be a key between the signing key and the
>    master key, this root key could have a one month rotation. Then this
>    root key could be used to have a daily generated signing key.
>
>    The disadvantage is that the root key and signing key would be
>    passphraseless to allow for automatic signing of either the signing
>    key and the dev key list. (assuming that manually entering keyphrases
>    daily is too much)
>
>    *) It might be possible to keep the passphrase for the daily signing
>       key in memory (or even the whole secret part, which would mean
>       that changes in developer keys would only be visible with a one
>       day delay (max) or manual regeneration of a signing key)
>
> Paul
>
> - --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@g.o
> Homepage: http://www.devrieze.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAYDetbKx5DBjWFdsRArC0AJ989ls+w+RszK7FazB0I8hq9//swQCg2BUA
> sXkzItayvUSKux+/rfHFx1w=
> =N+pp
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev@g.o mailing list
>
>

--
gentoo-dev@g.o mailing list