Disclaimer: I'll only targeting technical aspects here, I won't go into any security analysis.
On Thu, 18 May 2006 23:45:17 +0200 Patrick Lauer <[EMAIL PROTECTED]> wrote: > 3) Manifest / Manifest2 > > This is an implementation of a checksum / signature scheme. It is > described in GLEP 44: > > http://www.gentoo.org/proj/en/glep/glep-0044.html > > Right now SHA1, SHA256, RMD160 are the default checksum algorithms > > While manifest2 should take care of all executable bits in the tree it > does not yet cover eclasses and profiles. As long as this is not taken > care off any attacker can just override an eclass on the rsync mirror > or modify the profiles. This has a severe negative impact on signing > effectivity. > > Any "good" solution should sign all data files in the tree, so I ask > for an extension of the Manifest2 protocol to include _every_ data > file with no exception. partially covered with glep 33, definitely needs a repoman rewrite. > Key policies > ============ > > To make signing relevant and verifiable all devs should use the same > parameters - key length, key type, validity. > Once that is agreed upon a key distribution strategy is needed so that > users can get the key(s) on a verifiable path. From an implementation point of view the main questions here are: - how do we get the keys? (keyserver, stored in tree, ...) - how do we validate a key? > Signing strategies > ================== > > Once there is an agreement on what files to sign with what kind of > keys there remains the question how to sign it. There are at least > three strategies: > > Method "simple": > ---------------- > > Use one central key that is kept on a secure box. Signing is done > automatically after a commit. The key distribution is simple since > there > is only one key that has to be pushed. > Problems are security (single point of failure, single target for > compromising) > > Method "complex": > ----------------- > > Let every dev sign the files he adds or modifies. A keyring is > maintained on gentoo infrastructure and is distributed over multiple > paths. > Problems: Need support for multi-signing. If one file is added the > manifest should not be only signed by the last editor, only the > change should be signed. At the same time it needs to be kept simple > and fast, ssigning each file on its own or keeping infinite history > must be avoided. Keyring managment needs to be defined. Key > revocation etc. needs to be defined. > > Method "hybrid": > ---------------- > > Let every dev sign, add automatic server-side signing with a master > key. Gives you bits of both. Normal users can trust the master key. > Paranoid users can trust the dev keys. You're missing one option, the one currently in use: Any change to a package dir requires the package Manifest to be signed by the committing dev, including all files even if not changed by the commit. From an implementation POV it's desirable to only have one signature in a file, multiple signatures are problemtatic for parsing (for partial signatures) and verification (for both partial signatures and multiple full signatures). Detached signatures would make that easier, but are not an option due to overhead (>20k new files in the tree). Therefore I'd avoid the "complex" and "hybrid" solutions. > Some selected problems from there: > > * Access Control Lists could be used so that only toolchain people can > commit to glibc. Do we want that level of micromanagment? Does it > offer any security benefits? More a QA thing IMO, I don't see any security benefits. We've explicitly not done this in the past (technically it's not a problem, ACLs are used in other cvs modules). > * key revocation may be impractical - what methods for handling > retired devs and rogue devs are there? Part of the key policy. > * how to verify from an install CD ? key policy. > * in tree or out of band? Storing the keys in the tree is easy, but a > potential security problem key policy again. 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.
signature.asc
Description: PGP signature
