1 |
commit: 7f9bd9fa8aa0f21950a4c42e20fca1bc10f4c22c |
2 |
Author: Michał Górny <mgorny <AT> gentoo <DOT> org> |
3 |
AuthorDate: Mon Nov 20 17:22:40 2017 +0000 |
4 |
Commit: Michał Górny <mgorny <AT> gentoo <DOT> org> |
5 |
CommitDate: Mon Nov 20 17:22:40 2017 +0000 |
6 |
URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=7f9bd9fa |
7 |
|
8 |
glep-0074: Include suggestions from Daniel Campbell |
9 |
|
10 |
glep-0074.rst | 59 ++++++++++++++++++++++++++++++----------------------------- |
11 |
1 file changed, 30 insertions(+), 29 deletions(-) |
12 |
|
13 |
diff --git a/glep-0074.rst b/glep-0074.rst |
14 |
index 42c0c9e..6081937 100644 |
15 |
--- a/glep-0074.rst |
16 |
+++ b/glep-0074.rst |
17 |
@@ -19,7 +19,7 @@ Abstract |
18 |
======== |
19 |
|
20 |
This GLEP extends the Manifest file format to cover full-tree file |
21 |
-integrity and authenticity checks.The format aims to be future-proof, |
22 |
+integrity and authenticity checks. The format aims to be future-proof, |
23 |
efficient and provide means of backwards compatibility. |
24 |
|
25 |
|
26 |
@@ -435,7 +435,7 @@ The stand-alone format has been selected because of its three |
27 |
advantages: |
28 |
|
29 |
1. It is more future-proof. If an incompatible change to the repository |
30 |
- format is introduced, only developers need to be upgrade the tools |
31 |
+ format is introduced, only developers need to upgrade the tools |
32 |
they use to generate the Manifests. The tools used to verify |
33 |
the updated Manifests will continue to work. |
34 |
|
35 |
@@ -498,7 +498,7 @@ the following implications: |
36 |
|
37 |
While both models have their advantages, the hierarchical model was |
38 |
selected because it reduces the number of OpenPGP operations |
39 |
-which are comparatively costly to the minimum. |
40 |
+(which are comparatively costly) to the minimum. |
41 |
|
42 |
|
43 |
Tree layout restrictions |
44 |
@@ -606,14 +606,14 @@ the purpose of using ``MISC``. |
45 |
Finally, the non-strict mode could be used as means to an attack. |
46 |
The allowance of missing or modified documentation file could be used |
47 |
to spread misinformation, resulting in bad decisions made by the user. |
48 |
-A modified file could also be used e.g. to exploit vulnerabilities |
49 |
+A modified file could also be used, e.g. to exploit vulnerabilities |
50 |
of an XML parser. |
51 |
|
52 |
|
53 |
Timestamp field |
54 |
--------------- |
55 |
|
56 |
-The top-level Manifests optionally allows using a ``TIMESTAMP`` tag |
57 |
+The top-level Manifest optionally allows using a ``TIMESTAMP`` tag |
58 |
to include a generation timestamp in the Manifest. A similar feature |
59 |
was originally proposed in GLEP 58 [#GLEP58]_. |
60 |
|
61 |
@@ -622,10 +622,10 @@ A malicious third-party may use the principles of exclusion or replay |
62 |
the identity of clients to attack. The timestamp field can be used to |
63 |
detect that. |
64 |
|
65 |
-In order to provide a more complete protection, the Gentoo |
66 |
-Infrastructure should provide an ability to obtain the timestamps |
67 |
-of all Manifests from a recent timeframe over a secure channel |
68 |
-from a trusted source for comparison. |
69 |
+In order to provide more complete protection, the Gentoo Infrastructure |
70 |
+should provide an ability to obtain the timestamps of all Manifests |
71 |
+from a recent timeframe over a secure channel from a trusted source |
72 |
+for comparison. |
73 |
|
74 |
Strictly speaking, this information is already provided by the various |
75 |
``metadata/timestamp*`` files that are already present. However, |
76 |
@@ -635,7 +635,7 @@ and provides the ability to perform the verification stand-alone. |
77 |
Furthermore, some of the timestamp files are added very late |
78 |
in the distribution process, past the Manifest generation phase. Those |
79 |
files will most likely receive ``IGNORE`` entries and therefore |
80 |
-be not suitable to safe use. |
81 |
+be unsafe to use. |
82 |
|
83 |
The specification permits additional timestamps in sub-Manifest files |
84 |
for local use. A generic testing tool should ignore them. |
85 |
@@ -645,7 +645,7 @@ New vs deprecated tags |
86 |
---------------------- |
87 |
|
88 |
Out of the four types defined by Manifest2, only one is reused |
89 |
-and the remaining three is replaced by a single, universal ``DATA`` |
90 |
+and the remaining three are replaced by a single, universal ``DATA`` |
91 |
type. |
92 |
|
93 |
The ``DIST`` tag is reused since the specification does not change |
94 |
@@ -696,11 +696,11 @@ in the top-level Manifest. |
95 |
Injecting ChangeLogs into the checkout |
96 |
-------------------------------------- |
97 |
|
98 |
-One of the problems considered in the new Manifest format was that |
99 |
-of injecting historical and autogenerated ChangeLog into the repository. |
100 |
-Normally we are not including those files to reduce the checkout size. |
101 |
-However, some users have shown interest in them and Infra is working |
102 |
-on providing them via an additional rsync module. |
103 |
+One of the problems considered in the new Manifest format was injecting |
104 |
+historical and autogenerated ChangeLog into the repository. We normally |
105 |
+don't include those files, to reduce the checkout size. However, some |
106 |
+users have shown interest in them and Infra is working on providing them |
107 |
+via an additional rsync module. |
108 |
|
109 |
If such files were injected into the repository, they would cause |
110 |
verification failures of Manifests. To account for this, Infra could |
111 |
@@ -733,9 +733,9 @@ Hash algorithms |
112 |
--------------- |
113 |
|
114 |
While maintaining a consistent supported hash set is important |
115 |
-for interoperability, it is no good fit for the generic layout of this |
116 |
-GLEP. Furthermore, it would require updating the GLEP in the future |
117 |
-every time the used algorithms change. |
118 |
+for interoperability, it is not a good fit for the generic layout |
119 |
+of this GLEP. Furthermore, it would require updating the GLEP |
120 |
+in the future every time the used algorithms change. |
121 |
|
122 |
Instead, the specification focuses on listing the currently used |
123 |
algorithm names for interoperability, and sets a recommendation |
124 |
@@ -761,10 +761,11 @@ entries and to avoid confusion. |
125 |
|
126 |
The compression of top-level Manifest file has been prohibited |
127 |
as the specification currently does not provide any means of verifying |
128 |
-the file prior to decompression. This would make it possibly for |
129 |
-a malicious third party to provide a compressed Manifest exposing |
130 |
-decompressor vulnerabilities, or being a zip bomb, and the tooling |
131 |
-would have to unpack it before being able to verify the contents. |
132 |
+the file prior to decompression. If the top-level Manifest is |
133 |
+compressed, tooling will have to unpack the file before being able |
134 |
+to verify the contents. This makes it possible for a malicious third |
135 |
+party to attack the system by providing a compressed Manifest that |
136 |
+exposes decompressor vulnerabilities, or a zip bomb. |
137 |
|
138 |
The OpenPGP cleartext signature covers the contents of the Manifest, |
139 |
and is therefore compressed along with them. The possibility of using |
140 |
@@ -778,10 +779,10 @@ in a signed, uncompressed top-level Manifest. |
141 |
|
142 |
The existence of additional entries for uncompressed Manifest checksums |
143 |
was debated. However, plain entries for the uncompressed file would |
144 |
-be confusing if only compressed file existed, and conflicting if both |
145 |
-uncompressed and compressed variants existed. Furthermore, it has been |
146 |
-pointed out that ``DIST`` entries do not have uncompressed variant |
147 |
-either. |
148 |
+be confusing if only the compressed file existed, and conflicting |
149 |
+if both uncompressed and compressed variants existed. Furthermore, |
150 |
+it has been pointed out that ``DIST`` entries do not have uncompressed |
151 |
+variant either. |
152 |
|
153 |
|
154 |
Performance considerations |
155 |
@@ -792,7 +793,7 @@ performance concerns for end-user systems. The initial testing has shown |
156 |
that a cold-cache verification on a btrfs file system can take up around |
157 |
4 minutes, with the process being mostly I/O bound. On the other hand, |
158 |
it can be expected that the verification will be performed directly |
159 |
-after syncing, taking advantage of warm filesystem cache. |
160 |
+after syncing, taking advantage of a warm filesystem cache. |
161 |
|
162 |
To improve speed on I/O and/or CPU-restrained systems even further, |
163 |
the algorithms can be easily extended to perform incremental |
164 |
@@ -849,7 +850,7 @@ to the creation of this GLEP. This includes but is not limited to: |
165 |
- Ulrich Müller. |
166 |
|
167 |
Additionally, thanks to Robin Hugh Johnson for the original |
168 |
-MataManifest GLEP series which served both as inspiration and source |
169 |
+MetaManifest GLEP series which served both as inspiration and source |
170 |
of many concepts used in this GLEP. Recursively, also thanks to all |
171 |
the people who contributed to the original GLEPs. |