1 |
Hello, |
2 |
|
3 |
TL;DR: I'd like to disable thick Manifest support in Portage, in order |
4 |
to disable some of the compatibility quirks from MetaManifest format. |
5 |
All files would still be verified by gemato. |
6 |
|
7 |
|
8 |
We're using GLEP 74 MetaManifests for 2 years now. The specification |
9 |
was originally written to account for compatibility with existing |
10 |
(thick) Manifest files. I believe we can start considering removing |
11 |
at least some of that compatibility today. |
12 |
|
13 |
What I'd like to propose is disabling thick Manifests in the rsync |
14 |
variant of Gentoo repository (in layout.conf). This would cause Portage |
15 |
to stop verifying file entries directly (on-sync verification via gemato |
16 |
would still happen). Notably, this would limit the needed compatibility |
17 |
to DIST entries. |
18 |
|
19 |
Why? |
20 |
|
21 |
1. Thick Manifest verification happening in Portage is mostly redundant |
22 |
these days, and when it's not its advantages are weak. |
23 |
|
24 |
1a. Majority of Portage users are using on-sync verification via gemato. |
25 |
In this case, repeated partial checks from Portage are at most |
26 |
redundant. |
27 |
|
28 |
1b. While not using gemato, Portage verifies only leaf Manifests without |
29 |
checking the OpenPGP signature. There's no real security gain in this. |
30 |
|
31 |
1c. With transmission-level checksumming (and filesystem-level checksums |
32 |
becoming more common), there is no reason to assume we need to verify |
33 |
integrity of rsync result. |
34 |
|
35 |
2. Thick Manifest support in Portage is still relying on legacy entries. |
36 |
While technically we could either make Portage use gemato fully, or |
37 |
reimplement the new features, I don't think it's worth the effort given |
38 |
the above. |
39 |
|
40 |
2a. Removing legacy entries from ::gentoo will make it possible to |
41 |
remove the backwards compatibility code from gemato. We may also remove |
42 |
some of the redundant code from Portage. |
43 |
|
44 |
2b. We will gain the ability to use the new format more efficiently. |
45 |
In particular, I'm considering moving non-DIST entries to category-level |
46 |
Manifests and taking advantage of compression (but I don't know if it's |
47 |
going to provide real gain at the moment). |
48 |
|
49 |
3. Thick Manifests are generally PITA to power users and developers. |
50 |
|
51 |
3a. You need to regenerate them every time you edit an ebuild. It's |
52 |
like having to type 'yes, I really wanted to edit that file' every time. |
53 |
|
54 |
3b. You need to regenerate Manifests when moving ebuilds between git |
55 |
and rsync checkouts. |
56 |
|
57 |
3c. Proxied maintainers keep forgetting about that and submitting thick |
58 |
Manifests. |
59 |
|
60 |
|
61 |
WDYT? |
62 |
|
63 |
-- |
64 |
Best regards, |
65 |
Michał Górny |