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