1 |
W dniu nie, 29.10.2017 o godzinie 20∶54 +0000, użytkownik Robin H. |
2 |
Johnson napisał: |
3 |
> On Sun, Oct 29, 2017 at 07:47:41PM +0100, Michał Górny wrote: |
4 |
> ... |
5 |
> > > If users need other values, it's a package-manager config knob. |
6 |
> > |
7 |
> > We don't want pre-EAPI times where things will fail out of the box |
8 |
> > unless the user choose the one tool that got the whole list right |
9 |
> > and/or configure it to account for default list. |
10 |
> > |
11 |
> > I don't mind package manager providing the ability to ignore additional |
12 |
> > entries but the spec should work out of the box too. |
13 |
> |
14 |
> Ok, can we have a minor additions to the text then: |
15 |
> - The package manager may support additional user-specified IGNORE |
16 |
> entries, for usage where a user's processes need to inject additional |
17 |
> files that would not be ignored by existing rules (e.g. user commits |
18 |
> the rsync tree to CVS with -kb). |
19 |
|
20 |
Included. |
21 |
|
22 |
> Notes: |
23 |
> - distfiles/packages/local will be in IGNORE as distributed. |
24 |
> - package-manager might add lost+found if they have a filesystem just |
25 |
> for the tree. |
26 |
|
27 |
Not sure if we lost+found isn't actually common enough to be included |
28 |
in the standard set. But I'm fine either way. |
29 |
|
30 |
> > > Yes, put 'Verifying TIMESTAMP' into a new section as you added below, |
31 |
> > > including the out-of-date part there; don't detail how to verify it in |
32 |
> > > this section. |
33 |
> > |
34 |
> > I will try to do this today. |
35 |
> |
36 |
> Looks good. |
37 |
> |
38 |
> > |
39 |
> > > > > GLEP61, for the transition period, required compressed & uncompressed Manifests |
40 |
> > > > > in the same directory to have identical content. Include mention of that here. |
41 |
> > > > |
42 |
> > > > Can do. But I'll do it in 'Backwards compatibility' section: |
43 |
> > > > > - if the Manifest files inside the package directory are compressed, |
44 |
> > > > > a uncompressed file of identical content must coexist. |
45 |
> > > > > Saying that either can be used is a potential issue. |
46 |
> > > > |
47 |
> > > > Why? It also says that they must be identical, so it's of no difference |
48 |
> > > > to the implementation which one is used. |
49 |
> > > |
50 |
> > > It's safe if the identical requirement is there, and potentially unsafe otherwise. |
51 |
> > |
52 |
> > That's why they're both put in a *single sentence*? |
53 |
> |
54 |
> 'co-exist' in this context makes it the English parse weirdly to me, |
55 |
> that's why I was worried at first. |
56 |
> |
57 |
> Maybe a rewrite: |
58 |
> An uncompressed Manifest file inside a package directory MUST exist |
59 |
> during the transition period. A compressed Manifest of identical content |
60 |
> MAY be present. |
61 |
|
62 |
Done. |
63 |
|
64 |
> |
65 |
> > > > But it makes no sense when top-level Manifest is signed. This points out |
66 |
> > > > that for tools not supporting full-tree verification smaller signatures |
67 |
> > > > need to be used (skipping the fact that Portage did not ever implement |
68 |
> > > > it). |
69 |
> > > |
70 |
> > > The Manifests might not be signed by the same entity. |
71 |
> > > /metadata/glsa/Manifest might be signed by the security team, |
72 |
> > > /sec-policy/Manifest might be signed by SELinux team, |
73 |
> > > /Manifest should STILL be signed by Infra/tree-generation-process. |
74 |
> > |
75 |
> > I honestly doubt this will ever happen, and even if it does, it isn't |
76 |
> > really relevant to the spec at hand. My point was: if someone signs |
77 |
> > the whole repository, he normally will consider it pointless to sign |
78 |
> > individual package Manifests. This explains why he might consider it. |
79 |
> |
80 |
> My argument is that it make sense to permit multiple levels of signature |
81 |
> even when the top-level is signed: glsa-check could get ahead of the |
82 |
> Portage curve by verifying /metadata/glsa/Manifest using Gemato :-). |
83 |
> It doesn't need to verify the whole tree, just that directory. |
84 |
> |
85 |
> The package manager should decide about the GPG-verification of the |
86 |
> nested Manifests however, as they convey trust from different sources. |
87 |
|
88 |
Sure. Gemato currently verifies all signed files it finds. However, it |
89 |
only requires the top-level Manifest to be signed to consider the tree |
90 |
signed. |
91 |
|
92 |
I will submit an update once I process the other mail and do some |
93 |
clarifications wrt OPTIONAL. |
94 |
|
95 |
-- |
96 |
Best regards, |
97 |
Michał Górny |