1 |
Hello, |
2 |
|
3 |
I would like to propose a new attempt at Manifest signatures. Instead |
4 |
of using a single per-Manifest signature, we would keep separate |
5 |
signatures for each of the files, as an additional (optional) hash |
6 |
type. |
7 |
|
8 |
|
9 |
Motivation |
10 |
---------- |
11 |
The current signing approach gives all the responsibility for Manifest |
12 |
signature to the developer who committed last update to the ebuild |
13 |
directory regardless of the actual commit significance. |
14 |
|
15 |
Consider the following: Dev A is the primary package maintainer. He/she |
16 |
reviewed all the ebuilds and committed a signed Manifest. Then Dev B |
17 |
performs a slight cleanup of the ebuild directory. He/she modifies |
18 |
metadata.xml a little and/or removes an old ebuild. |
19 |
|
20 |
The actual ebuilds weren't modified -- yet Dev B has to sign all |
21 |
of them once again. Moreover, if Dev B doesn't use Manifest signing, |
22 |
the signature from Dev A is lost. |
23 |
|
24 |
|
25 |
The solution |
26 |
------------ |
27 |
As a solution for this I suggest making the GPG signatures per-file, |
28 |
simply creating an additional hash type for them. For example, |
29 |
a single Manifest line would look like: |
30 |
|
31 |
EBUILD foo-1.ebuild 1000 RMD160 ... SHA1 ... SHA256 ... GPG ... |
32 |
|
33 |
Where the GPG signature will be an explicit signature done by the dev |
34 |
modifying (or reviewing) a particular file. Then, if another dev |
35 |
modifies a single file, the signatures for other files would be |
36 |
untouched. |
37 |
|
38 |
|
39 |
Potential issues |
40 |
---------------- |
41 |
This signing model does not provide a mechanism for signing file |
42 |
removals. In other words, if a dev does remove files only, he/she won't |
43 |
leave any signature changes at all. If there's a reason to do that, we |
44 |
can consider using a complete Manifest file signature in parallel. |
45 |
|
46 |
-- |
47 |
Best regards, |
48 |
Michał Górny |