1 |
commit: f98cabc0c30dc18f5b602865eb8e84abf429ba8d |
2 |
Author: Michał Górny <mgorny <AT> gentoo <DOT> org> |
3 |
AuthorDate: Mon Oct 30 16:28:34 2017 +0000 |
4 |
Commit: Michał Górny <mgorny <AT> gentoo <DOT> org> |
5 |
CommitDate: Mon Oct 30 16:29:26 2017 +0000 |
6 |
URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=f98cabc0 |
7 |
|
8 |
glep-0074: Reorganize to have tag references after basic algos |
9 |
|
10 |
Reorganize so that file & timestamp verification come first, then tag |
11 |
references, then specialized algos and other informational sections. |
12 |
Rename 'new Manifest tags' to 'modern ...' since some of them are old. |
13 |
|
14 |
glep-0074.rst | 48 ++++++++++++++++++++++++------------------------ |
15 |
1 file changed, 24 insertions(+), 24 deletions(-) |
16 |
|
17 |
diff --git a/glep-0074.rst b/glep-0074.rst |
18 |
index d476ff3..a37ad34 100644 |
19 |
--- a/glep-0074.rst |
20 |
+++ b/glep-0074.rst |
21 |
@@ -163,8 +163,30 @@ reject any package or even the whole repository if it may refer to files |
22 |
for which the verification failed. |
23 |
|
24 |
|
25 |
-New Manifest tags |
26 |
------------------ |
27 |
+Timestamp verification |
28 |
+---------------------- |
29 |
+ |
30 |
+The Manifest file can contain a ``TIMESTAMP`` entry to account |
31 |
+for attacks against tree update distribution. If such an entry |
32 |
+is present, it should be updated every time at least one |
33 |
+of the Manifests changes. Every unique timestamp value must correspond |
34 |
+to a single tree state. |
35 |
+ |
36 |
+During the verification process, the client should compare the timestamp |
37 |
+against the update time obtained from a local clock or a trusted time |
38 |
+source. If the comparison result indicates that the Manifest at the time |
39 |
+of receiving was already significantly outdated, the client should |
40 |
+either fail the verification or require manual confirmation from user. |
41 |
+ |
42 |
+Furthermore, the Manifest provider may employ additional methods |
43 |
+of distributing the timestamps of recently generated Manifests |
44 |
+using a secure channel from a trusted source for exact comparison. |
45 |
+The exact details of such a solution are outside the scope of this |
46 |
+specification. |
47 |
+ |
48 |
+ |
49 |
+Modern Manifest tags |
50 |
+-------------------- |
51 |
|
52 |
The Manifest files can specify the following tags: |
53 |
|
54 |
@@ -228,28 +250,6 @@ allowed at the package directory level: |
55 |
to ``files/`` subdirectory. |
56 |
|
57 |
|
58 |
-Timestamp verification |
59 |
----------------------- |
60 |
- |
61 |
-The Manifest file can contain a ``TIMESTAMP`` entry to account |
62 |
-for attacks against tree update distribution. If such an entry |
63 |
-is present, it should be updated every time at least one |
64 |
-of the Manifests changes. Every unique timestamp value must correspond |
65 |
-to a single tree state. |
66 |
- |
67 |
-During the verification process, the client should compare the timestamp |
68 |
-against the update time obtained from a local clock or a trusted time |
69 |
-source. If the comparison result indicates that the Manifest at the time |
70 |
-of receiving was already significantly outdated, the client should |
71 |
-either fail the verification or require manual confirmation from user. |
72 |
- |
73 |
-Furthermore, the Manifest provider may employ additional methods |
74 |
-of distributing the timestamps of recently generated Manifests |
75 |
-using a secure channel from a trusted source for exact comparison. |
76 |
-The exact details of such a solution are outside the scope of this |
77 |
-specification. |
78 |
- |
79 |
- |
80 |
Algorithm for full-tree verification |
81 |
------------------------------------ |