On Sun, May 1, 2011 at 7:31 PM, Brian Harring <ferri...@gmail.com> wrote: > Get at that key, and you've got the tree, versus the current form, > crack all signing keys and you've got the tree.
Well, more like get any one of the keys and you get the tree, since portage only validates that a trusted key signed a package, and not that the key belonged to the package maintainer. In any case, the whole way that manifest signing works does not really preserve a signature from end-to-end. If I sign three files and somebody else signs two files, they end up overwriting my signature. So, if a mirror checks all the sigs, makes a change, and re-signs with its own key that isn't much less secure than what we have now. I wouldn't actually distribute the work all the way to the mirrors though - I'd have a central server generate the changelogs, sign them, and then propagate that to the mirror network. You just need to protect that one server really well then. If you really want to have dev->user trust with no broken links then the signatures would need to be associated with each file - not just the whole manifest. Plus, the local portage would need to check the metadata cache for consistency. In any case, I see manifest signing as a relatively minor issue here. It seems like the more fundamental debate is how much metadata we really should be distributing all the way to end-user systems, vs keeping it in a repository like a cvs log. Sure, offline access is useful, but the question is whether it is useful enough. My personal feeling is that we should keep the changelogs as-is, and include removals, until we're on git. Then we should re-evaluate. Rich
