Gentoo Archives: gentoo-commits

From: "Michał Górny" <mgorny@g.o>
To: gentoo-commits@l.g.o
Subject: [gentoo-commits] data/glep:glep-manifest commit in: /
Date: Sun, 29 Oct 2017 19:05:41
Message-Id: 1509303881.1c6b710facff36be31f3f53c10fdbc1b70f52e5d.mgorny@gentoo
1 commit: 1c6b710facff36be31f3f53c10fdbc1b70f52e5d
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: Sun Oct 29 19:04:41 2017 +0000
6 URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=1c6b710f
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.