1 |
On Sun, Oct 03, 2010 at 09:58:48AM +0200, Micha?? G??rny wrote: |
2 |
> The current signing approach gives all the responsibility for Manifest |
3 |
> signature to the developer who committed last update to the ebuild |
4 |
> directory regardless of the actual commit significance. |
5 |
> |
6 |
> Consider the following: Dev A is the primary package maintainer. He/she |
7 |
> reviewed all the ebuilds and committed a signed Manifest. Then Dev B |
8 |
> performs a slight cleanup of the ebuild directory. He/she modifies |
9 |
> metadata.xml a little and/or removes an old ebuild. |
10 |
> |
11 |
> The actual ebuilds weren't modified -- yet Dev B has to sign all |
12 |
> of them once again. Moreover, if Dev B doesn't use Manifest signing, |
13 |
> the signature from Dev A is lost. |
14 |
This exact problem was raised in 2003, as some of the early tree-signing |
15 |
discussion. If you haven't read my endnote to GLEP57, I strongly |
16 |
encourage you to do so. |
17 |
|
18 |
The end question from many of those discussions, on the matter of |
19 |
internal signature in the Manifest was: |
20 |
Why are VCS annotations on the unchanged files not enough? |
21 |
$ cvs annotate Manifest |
22 |
That can clearly show you the lines that have not changed, regardless of |
23 |
how many times the Manifest is signed and resigned. |
24 |
|
25 |
The best (and simultaneously worse) solution that turned up in the prior |
26 |
versions was the proposed appending of new data to Manifests, not |
27 |
replacing. The new data had to be signed however, otherwise it opened up |
28 |
a new way to exploit the security. And if you're signing the new data, |
29 |
there is no problem to just resign all of it. |
30 |
|
31 |
> The solution |
32 |
> ------------ |
33 |
I would like to thank you for a new insight into the problem. |
34 |
Your solution is sufficiently novel that none of the prior proposals are |
35 |
anything like it. |
36 |
|
37 |
> As a solution for this I suggest making the GPG signatures per-file, |
38 |
> simply creating an additional hash type for them. For example, |
39 |
> a single Manifest line would look like: |
40 |
> |
41 |
> EBUILD foo-1.ebuild 1000 RMD160 ... SHA1 ... SHA256 ... GPG ... |
42 |
I'm assuming you are proposing taking the ascii-armoured detached |
43 |
signature here, stripping the newlines (except the last one, which needs |
44 |
to be kept as a separate field), and using that. |
45 |
|
46 |
Alternatively base64 encode the non-armoured binary detached signature |
47 |
ourselves. Very little difference in the two ultimately however. |
48 |
|
49 |
> Where the GPG signature will be an explicit signature done by the dev |
50 |
> modifying (or reviewing) a particular file. Then, if another dev |
51 |
> modifies a single file, the signatures for other files would be |
52 |
> untouched. |
53 |
|
54 |
> Potential issues |
55 |
> ---------------- |
56 |
> This signing model does not provide a mechanism for signing file |
57 |
> removals. In other words, if a dev does remove files only, he/she won't |
58 |
> leave any signature changes at all. If there's a reason to do that, we |
59 |
> can consider using a complete Manifest file signature in parallel. |
60 |
Some more issues for you: |
61 |
1. Increases the size of the Manifest by a minimum of 710 bytes _per_ |
62 |
file. (4 bytes for 'GPG ', 700-900 for the hash, 1 for the field space, 5-12 bytes for the |
63 |
trailer). |
64 |
1.1. 55907 Manifest2 entries need this signing, so that's a ~38MiB |
65 |
increase in the tree size. |
66 |
2. Impossible to validate without Portage itself, or at least another |
67 |
tool to convert the signature back into a form readable by GnuPG. |
68 |
|
69 |
|
70 |
-- |
71 |
Robin Hugh Johnson |
72 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
73 |
E-Mail : robbat2@g.o |
74 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |