1 |
commit: 2e0621bfffc48ca8f842215f39f1bf218f708902 |
2 |
Author: Michał Górny <mgorny <AT> gentoo <DOT> org> |
3 |
AuthorDate: Sat Oct 28 11:49:39 2017 +0000 |
4 |
Commit: Michał Górny <mgorny <AT> gentoo <DOT> org> |
5 |
CommitDate: Mon Nov 13 16:33:01 2017 +0000 |
6 |
URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=2e0621bf |
7 |
|
8 |
glep-0074: Update based on feedback from Robin H. Johnson |
9 |
|
10 |
glep-0074.rst | 66 ++++++++++++++++++++++++++++++++++++++++++++++------------- |
11 |
1 file changed, 52 insertions(+), 14 deletions(-) |
12 |
|
13 |
diff --git a/glep-0074.rst b/glep-0074.rst |
14 |
index e9f8bad..425381f 100644 |
15 |
--- a/glep-0074.rst |
16 |
+++ b/glep-0074.rst |
17 |
@@ -8,7 +8,7 @@ Type: Standards Track |
18 |
Status: Draft |
19 |
Version: 1 |
20 |
Created: 2017-10-21 |
21 |
-Last-Modified: 2017-10-26 |
22 |
+Last-Modified: 2017-10-29 |
23 |
Post-History: 2017-10-26 |
24 |
Content-Type: text/x-rst |
25 |
Requires: 59, 61 |
26 |
@@ -49,7 +49,7 @@ This specification is designed with the following goals in mind: |
27 |
1. It should provide means to ensure the authenticity of the complete |
28 |
repository, including preventing the injection of additional files. |
29 |
|
30 |
-2. Alike the original Manifest2, the files should be split into two |
31 |
+2. Like the original Manifest2, the files should be split into two |
32 |
groups — files whose authenticity is critical, and those whose |
33 |
mismatch may be accepted in non-strict mode. The same classification |
34 |
should apply both to files listed in Manifests, and to stray files |
35 |
@@ -115,11 +115,11 @@ The file entries (except for ``IGNORE``) can be specified for regular |
36 |
files only. Symbolic links are followed when opening files. It is |
37 |
an error to specify an entry for a different file type. |
38 |
|
39 |
-All the files covered by a Manifest tree must reside on the same |
40 |
-filesystem. It is an error to specify entries applying to files |
41 |
-on another filesystem. If subdirectories of the Manifest tree reside |
42 |
-on a different filesystem, they must be explicitly excluded |
43 |
-via ``IGNORE``. |
44 |
+All the local (non-``DIST``) files covered by a Manifest tree must |
45 |
+reside on the same filesystem. It is an error to specify entries |
46 |
+applying to files on another filesystem. If subdirectories |
47 |
+of the Manifest tree reside on a different filesystem, they must |
48 |
+be explicitly excluded via ``IGNORE``. |
49 |
|
50 |
|
51 |
File verification |
52 |
@@ -156,7 +156,8 @@ The Manifest files can specify the following tags: |
53 |
combined date and time in UTC timezone, i.e. using the following |
54 |
``strftime()`` format string: ``%Y-%m-%dT%H:%M:%SZ``. Optionally used |
55 |
in the top-level Manifest file. The package manager can use it |
56 |
- to detect an outdated repository checkout. |
57 |
+ to detect an outdated repository checkout as described in `Timestamp |
58 |
+ verification`_. |
59 |
|
60 |
``MANIFEST <path> <size> <checksums>…`` |
61 |
Specifies a sub-Manifest. The sub-Manifest must be verified like |
62 |
@@ -209,6 +210,28 @@ allowed at the package directory level: |
63 |
to ``files/`` subdirectory. |
64 |
|
65 |
|
66 |
+Timestamp verification |
67 |
+---------------------- |
68 |
+ |
69 |
+The Manifest file can contain a ``TIMESTAMP`` entry to account |
70 |
+for attacks against tree update distribution. If such an entry |
71 |
+is present, it should be updated every time at least one |
72 |
+of the Manifests changes. Every unique timestamp value must correspond |
73 |
+to a single tree state. |
74 |
+ |
75 |
+During the verification process, the client should compare the timestamp |
76 |
+against the update time obtained from a local clock or a trusted time |
77 |
+source. If the comparison result indicates that the Manifest at the time |
78 |
+of receiving was already significantly outdated, the client should |
79 |
+either fail the verification or require manual confirmation from user. |
80 |
+ |
81 |
+Furthermore, the Manifest provider may employ additional methods |
82 |
+of distributing the timestamps of recently generated Manifests |
83 |
+using a secure channel from a trusted source for exact comparison. |
84 |
+The exact details of such a solution are outside the scope of this |
85 |
+specification. |
86 |
+ |
87 |
+ |
88 |
Algorithm for full-tree verification |
89 |
------------------------------------ |
90 |
|
91 |
@@ -218,8 +241,9 @@ can be used: |
92 |
1. Collect all files present in the repository into *present* set. |
93 |
|
94 |
2. Start at the top-level Manifest file. Verify its OpenPGP signature. |
95 |
- Optionally verify the ``TIMESTAMP`` entry if present. Remove |
96 |
- the top-level Manifest from the *present* set. |
97 |
+ Optionally verify the ``TIMESTAMP`` entry if present as specified |
98 |
+ in `timestamp verification`. Remove the top-level Manifest |
99 |
+ from the *present* set. |
100 |
|
101 |
3. Process all ``MANIFEST`` entries, recursively. Verify the Manifest |
102 |
files according to `file verification`_ section, and include their |
103 |
@@ -232,7 +256,11 @@ can be used: |
104 |
5. Collect all files covered by ``DATA``, ``MISC``, ``OPTIONAL``, |
105 |
``EBUILD`` and ``AUX`` entries into the *covered* set. |
106 |
|
107 |
-6. Verify all the files in the union of the *present* and *covered* |
108 |
+6. Verify the entries in *covered* set for incompatible duplicates |
109 |
+ and collisions with ignored files as explained in `Manifest file |
110 |
+ locations and nesting`_. |
111 |
+ |
112 |
+7. Verify all the files in the union of the *present* and *covered* |
113 |
sets, according to `file verification`_ section. |
114 |
|
115 |
|
116 |
@@ -489,8 +517,15 @@ The top-level Manifests optionally allows using a ``TIMESTAMP`` tag |
117 |
to include a generation timestamp in the Manifest. A similar feature |
118 |
was originally proposed in GLEP 58 [#GLEP58]_. |
119 |
|
120 |
-The timestamp can be used to detect delay or replay attacks against |
121 |
-Gentoo mirrors. |
122 |
+A malicious third-party may use the principles of exclusion and replay |
123 |
+to deny an update to clients, while at the same time recording |
124 |
+the identity of clients to attack. The timestamp field can be used |
125 |
+to detect that. |
126 |
+ |
127 |
+In order to provide a more complete protection, the Gentoo |
128 |
+Infrastructure should provide an ability to obtain the timestamps |
129 |
+of all Manifests from a recent timeframe over a secure channel |
130 |
+from a trusted source for comparison. |
131 |
|
132 |
Strictly speaking, this is already provided by the various |
133 |
``metadata/timestamp.*`` files provided already by Gentoo which are also |
134 |
@@ -662,7 +697,10 @@ ensured: |
135 |
the deprecated ``EBUILD`` tag (rather than ``DATA``), |
136 |
|
137 |
- the Manifest files inside the package directory can be signed |
138 |
- to provide authenticity verification. |
139 |
+ to provide authenticity verification, |
140 |
+ |
141 |
+- if the Manifest files inside the package directory are compressed, |
142 |
+ a uncompressed file of identical content must coexist. |
143 |
|
144 |
Once the backwards compatibility is no longer a concern, the above |
145 |
no longer needs to hold and the deprecated tags can be removed. |