1 |
On Sat, Oct 28, 2017 at 01:50:46PM +0200, Michał Górny wrote: |
2 |
> > A SVN or Git repo might also have dot-named directories. |
3 |
> I like the implicit idea better as it is more consistent with normal |
4 |
> tool behavior, like 'ls' not listing the files. Dotfiles can be created |
5 |
> by many random tools or even the filesystem (especially in some cases |
6 |
> of overlay filesystems). |
7 |
> |
8 |
> That said, the case of 'lost+found' just occurred to me. I suppose this |
9 |
> one we will want to always IGNORE. |
10 |
Thought: make the package manager responsible for their own ignore list |
11 |
in addition to the IGNORE values; and by default it can contain a |
12 |
partial overlap with the IGNORE manifest entries. |
13 |
**/.git |
14 |
/lost+found # ignore at the top-level only |
15 |
/distfiles # ignore at the top-level only |
16 |
/packages # ignore at the top-level only |
17 |
/local # ignore at the top-level only |
18 |
|
19 |
If users need other values, it's a package-manager config knob. |
20 |
|
21 |
> Let's try: |
22 |
> |
23 |
> | 2. Start at the top-level Manifest file. Verify its OpenPGP signature. |
24 |
> | Optionally verify the ``TIMESTAMP`` entry if present. |
25 |
> | If the timestamp is significantly out of date compared to the local |
26 |
> | clock or a trusted source, halt or require manual intervention |
27 |
> | from the user. Remove the top-level Manifest from the *present* set. |
28 |
> |
29 |
> Maybe it would look better if I split it into sub-points. |
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 |
> > GLEP61, for the transition period, required compressed & uncompressed Manifests |
35 |
> > in the same directory to have identical content. Include mention of that here. |
36 |
> Can do. But I'll do it in 'Backwards compatibility' section: |
37 |
> | - if the Manifest files inside the package directory are compressed, |
38 |
> | a uncompressed file of identical content must coexist. |
39 |
> > Saying that either can be used is a potential issue. |
40 |
> Why? It also says that they must be identical, so it's of no difference |
41 |
> to the implementation which one is used. |
42 |
It's safe if the identical requirement is there, and potentially unsafe otherwise. |
43 |
|
44 |
> > > Tree design |
45 |
> > > ----------- |
46 |
> > Add a minor header here, to say this is the end of the 'Tree design' section? |
47 |
> It's not the end, it's description of the alternative. Both belong |
48 |
> in one section. I could add additional section level but I'd rather |
49 |
> not do that for a single use. |
50 |
Hmm, just reads unclear if that should have been a different section. |
51 |
Not sure if there is a nice way to fix it at all. |
52 |
|
53 |
> > > Timestamp field |
54 |
> | A malicious third-party may use the principles of exclusion and replay |
55 |
> | to deny an update to clients, while at the same time recording |
56 |
> | the identity of clients to attack. The timestamp field can be used |
57 |
> | to detect that. |
58 |
> | |
59 |
> | In order to provide a more complete protection, the Gentoo |
60 |
> | Infrastructure should provide an ability to obtain the timestamps |
61 |
> | of all Manifests from a recent timeframe over a secure channel |
62 |
> | for comparison. |
63 |
> | |
64 |
> | Strictly speaking, this is already provided by the various |
65 |
> | ``metadata/timestamp.*`` files provided already by Gentoo which are also |
66 |
> | covered by the Manifest. However, including the value in the Manifest |
67 |
> | itself has a little cost and provides the ability to perform |
68 |
> | the verification stand-alone. |
69 |
Just add in the sentence re trusted source from before, otherwise good. |
70 |
The rest of this thread devolved into specifics about implementing the |
71 |
validation; which aren't relevant to this GLEP (yes, telling the package |
72 |
manager that it's a known old tree, ignore the age only, is a valid use |
73 |
case). |
74 |
|
75 |
|
76 |
> > Could we please note here, for the transitional period, that the |
77 |
> > file equivalence rule is applicable? |
78 |
> > During the transitional, the package Manifests may contain two entries for a |
79 |
> > given file: (DATA, EBUILD) or (DATA, AUX). The MISC type remains the |
80 |
> > same. |
81 |
> Equivalence rule is applicable always. However, there's no point |
82 |
> in duplicating the entry for the same file as that's only going |
83 |
> to increase space use. |
84 |
This means that new verification tools (beyond Gemato) need to handle |
85 |
the legacy types for the moment, and can't just skip them (eg if both |
86 |
entries existed). |
87 |
|
88 |
> > > - the Manifest files inside the package directory can be signed |
89 |
> > > to provide authenticity verification. |
90 |
> > Why do we need to specify this in backwards compat, it's still permitted above. |
91 |
> But it makes no sense when top-level Manifest is signed. This points out |
92 |
> that for tools not supporting full-tree verification smaller signatures |
93 |
> need to be used (skipping the fact that Portage did not ever implement |
94 |
> it). |
95 |
The Manifests might not be signed by the same entity. |
96 |
/metadata/glsa/Manifest might be signed by the security team, |
97 |
/sec-policy/Manifest might be signed by SELinux team, |
98 |
/Manifest should STILL be signed by Infra/tree-generation-process. |
99 |
|
100 |
-- |
101 |
Robin Hugh Johnson |
102 |
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer |
103 |
E-Mail : robbat2@g.o |
104 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
105 |
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |