On Tue, Sep 13, 2011 at 04:38:35AM +0000, Robin H. Johnson wrote: > On Tue, Sep 13, 2011 at 03:20:35AM +0000, Zac Medico wrote: > > commit: 677240f7b3db66bdcd403c214e5d3fa30e31a24a > > Author: Zac Medico <zmedico <AT> gentoo <DOT> org> > > AuthorDate: Tue Sep 13 03:20:00 2011 +0000 > > Commit: Zac Medico <zmedico <AT> gentoo <DOT> org> > > CommitDate: Tue Sep 13 03:20:00 2011 +0000 > > URL: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=677240f7 > > > > repoman: don't sign thin manifests > > > > Thin manifests imply reliance on the VCS for file integrity, > > which implies that manifest signatures are not needed. > > This is only true after the VCS has signed commits. > > If the VCS does not have signed commits, then we should have this > signature.
This really doesn't provide for much; without a chain of trust to the content of layout.conf, you can't toggle behaviour (making lack of signing a failure) for example. So the manager has to either trust the VCS validity, or require accept mixed signed/unsigned (which opens a new branch of attacks). Worse, what this tries to protect against is the VCS being screwed with- by definition, thin defers that to the VCS, instead providing the data of what the VCS cannot, the distfiles checksums. If an attack on the VCS can be done (whether SHA1 breakage, or just in the middle branch injection), an attacker can just as easily inject in a patch to files/ along w/ a modification to the ebuild to include that trojan. It's a bit harsher than I'd like, but signed thin manifests are security theater as best I can tell. While I grok your concerns, it would be *very* useful to know exactly what attacks a signed manifest precludes that a thin manifest doesn't; all I see is remote distfiles manipulation w/ a branch injection; that same injection can just as easily mangle profile.bashrc, the ebuild itself, or slip patches into files. If it doesn't actually do anything, it should be disabled. On the portage front, this just change portage behaviour to defaulting to signing, rather than configuration based- very least that deserves a PSA notice... ~brian
