From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B22FD138334 for ; Mon, 10 Jun 2019 15:58:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 678DAE0844; Mon, 10 Jun 2019 15:58:25 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8E3AAE0844 for ; Mon, 10 Jun 2019 15:58:24 +0000 (UTC) Received: from oystercatcher.gentoo.org (unknown [IPv6:2a01:4f8:202:4333:225:90ff:fed9:fc84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id F210534576E for ; Mon, 10 Jun 2019 15:58:22 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id EB6655C0 for ; Mon, 10 Jun 2019 15:58:20 +0000 (UTC) From: "Ulrich Müller" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Ulrich Müller" Message-ID: <1560182180.dedd8451ef7110167d0c7ed575a29229bd5daa68.ulm@gentoo> Subject: [gentoo-commits] data/glep:master commit in: / X-VCS-Repository: data/glep X-VCS-Files: glep-0057.rst glep-0058.rst glep-0059.rst glep-0060.rst X-VCS-Directories: / X-VCS-Committer: ulm X-VCS-Committer-Name: Ulrich Müller X-VCS-Revision: dedd8451ef7110167d0c7ed575a29229bd5daa68 X-VCS-Branch: master Date: Mon, 10 Jun 2019 15:58:20 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-Archives-Salt: de9066a9-72b9-4957-a047-dca1a038d604 X-Archives-Hash: 71d5194b28acdf709dcca324b0d200b9 commit: dedd8451ef7110167d0c7ed575a29229bd5daa68 Author: Ulrich Müller gentoo org> AuthorDate: Mon Jun 10 15:56:20 2019 +0000 Commit: Ulrich Müller gentoo org> CommitDate: Mon Jun 10 15:56:20 2019 +0000 URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=dedd8451 glep-{0057,0058,0059,0060}: Fix syntax of cross references. Signed-off-by: Ulrich Müller gentoo.org> glep-0057.rst | 10 +++++----- glep-0058.rst | 20 ++++++++++---------- glep-0059.rst | 18 +++++++++--------- glep-0060.rst | 10 +++++----- 4 files changed, 29 insertions(+), 29 deletions(-) diff --git a/glep-0057.rst b/glep-0057.rst index ef7112b..588e42b 100644 --- a/glep-0057.rst +++ b/glep-0057.rst @@ -108,10 +108,10 @@ security needs to be implemented: - Tree and distfile distribution from Infrastructure to Users, via the mirrors (this includes both HTTP and rsync distribution). -Both processes need their security improved. In [GLEPxx2] we will discuss +Both processes need their security improved. In [GLEPxx2]_ we will discuss how to improve the security of the first process. The relatively speaking simpler process of file distribution will be described in -[GLEP58]. Since it can be implemented without having to change the +[GLEP58]_. Since it can be implemented without having to change the workflow and behaviour of developers we hope to get it done in a reasonably short timeframe. @@ -142,7 +142,7 @@ protection against this class of attacks is very easy to implement with little added cost. At the level of mirrors, addition of malicious content is not the only -attack. As discussed by Cappos et al [C08a,C08b], an attacker may use +attack. As discussed by Cappos et al [C08a]_, [C08b]_, an attacker may use exclusion and replay attacks, possibly only on a specific subset of user to extend the window of opportunity on another exploit. @@ -153,7 +153,7 @@ modifications to our development process), as a malicious developer is fully authorized to provide materials for distribution. Partial protection can be gained by Portage and Infrastructure changes, but the real improvements needed are developer education and continued -vigilance. This is further discussed in [GLEPxx2]. +vigilance. This is further discussed in [GLEPxx2]_. This security is still limited in scope - protection against compromised developers is very expensive, and even complex systems like peer review @@ -168,7 +168,7 @@ cannot be complete (as the User may be attacked directly), we can ensure that Gentoo infrastructure and the mirrors are not a weak point. This objective is actually much closer than it seems already - most of the work has been completed for other things! This is further discussed in -[GLEP58]. As this process has the most to gain in security, and the +[GLEP58]_. As this process has the most to gain in security, and the most immediate impact, it should be implemented before or at the same time as any changes to process #1. Security at this layer is already available in the signed daily snapshots, but we can extend it to cover diff --git a/glep-0058.rst b/glep-0058.rst index d54b160..9602a72 100644 --- a/glep-0058.rst +++ b/glep-0058.rst @@ -55,7 +55,7 @@ No other guarantees, either implicit or explicit are made. Additionally, distributing a set of the most recent MetaManifests from a trusted source allows validation of trees that come from community mirrors, and allows detection of all cases of malicious mirrors (either -by deliberate delay, replay [C08a, C08b] or alteration). +by deliberate delay, replay [C08a]_, [C08b]_ or alteration). ============= Specification @@ -100,10 +100,10 @@ Process: packages, local. 2. If a directory contains a Manifest file, extract all relevant local files from it (presently: AUX, MISC, EBUILD; but should follow the - evolution of Manifest2 entry types per [GLEP60]), and place them + evolution of Manifest2 entry types per [GLEP60]_), and place them into the COVERED set. 3. Recursively add every file in the directory to the ALL set, - pursuant to the exclusion list as mentioned in [GLEP60]. + pursuant to the exclusion list as mentioned in [GLEP60]_. 4. Produce a new set, UNCOVERED, as the set-difference (ALL)-(COVERED). This is every item that is not covered by another Manifest, or part @@ -129,14 +129,14 @@ Process: tarball signing is sufficient. 2. For the future, the key used for fully automated signing by infra should not be on the same keyring as developer keys. See - [GLEPxx3] for further notes. + [GLEPxx3]_ for further notes. Notes: ====== -The above does not conflict the proposal contained in [GLEP33], which +The above does not conflict the proposal contained in [GLEP33]_, which restructure eclasses to include subdirectories and Manifest files, as the Manifest rules above still provide indirect verification for all -files after the [GLEP33] restructuring if it comes to pass. +files after the [GLEP33]_ restructuring if it comes to pass. Additional levels of Manifests are required, such as per-category, and in the eclasses, profiles and metadata directories. This ensures that a @@ -166,10 +166,10 @@ Procedure for verifying an item in the MetaManifest: In the following, I've used term 'M2-verify' to note following the hash verification procedures as defined by the Manifest2 format - which compromise checking the file length, and that the hashes match. Which -filetypes may be ignored on missing is discussed in [GLEP60]. +filetypes may be ignored on missing is discussed in [GLEP60]_. 1. Check the GnuPG signature on the MetaManifest against the keyring of - automated Gentoo keys. See [GLEPxx3] for full details regarding + automated Gentoo keys. See [GLEPxx3]_ for full details regarding verification of GnuPG signatures. 1. Abort if the signature check fails. @@ -233,14 +233,14 @@ validation. -------------------------------------------- MetaManifest and the new Manifest2 filetypes -------------------------------------------- -While [GLEP60] describes the addition of new filetypes, these are NOT +While [GLEP60]_ describes the addition of new filetypes, these are NOT needed for implementation of the MetaManifest proposal. Without the new filetypes, all entries in the MetaManifest would be of type 'MISC'. ---------------------------------------------------- Timestamps & Additional distribution of MetaManifest ---------------------------------------------------- -As discussed by [C08a,C08b], malicious third-party mirrors may use the +As discussed by [C08a]_, [C08b]_, malicious third-party mirrors may use the principles of exclusion and replay to deny an update to clients, while at the same time recording the identity of clients to attack. diff --git a/glep-0059.rst b/glep-0059.rst index 9a9822f..035ee45 100644 --- a/glep-0059.rst +++ b/glep-0059.rst @@ -34,7 +34,7 @@ security of the tree - and a comprehensive security plan is needed. This GLEP is not mandatory for the tree-signing specification, but instead aims to improve the security of the hashes used in Manifest2 -[GLEP44]. As such, it is also able to stand on its own. +[GLEP44]_. As such, it is also able to stand on its own. Specification ============= @@ -48,20 +48,20 @@ is that multiple checksums would be an increase in security, but we could not provably quantify the amount of security this added. The really bad news, is that this position is completely and utterly wrong. Many of you will be aghast at this. There is extremely little -added security in multiple checksums as noted by Joux [J04]. For any set +added security in multiple checksums as noted by Joux [J04]_. For any set of checksums, the actual strength lies in that of the strongest checksum. -Wang et al [W04] extended Joux's [J04] work on SHA-0 to cover MD4, MD5, +Wang et al [W04]_ extended Joux's [J04]_ work on SHA-0 to cover MD4, MD5, HAVAL-128 and RIPEMD families of hashes. How fast can MD5 be broken? --------------------------- For a general collision, not a pre-image attack, since the announcement -by Wang et al [W04], the time required to break MD5 has been massively +by Wang et al [W04]_, the time required to break MD5 has been massively reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and estimated at 64 hours with a Pentium-3 1.7Ghz. This has gone down to -less than in two years, to 17 seconds [K06a]. +less than in two years, to 17 seconds [K06a]_. - 08/2004 - 1 hour, IBM pSeries 690 (32x 1.7Ghz POWER4+) = 54.4 GHz-Hours @@ -78,11 +78,11 @@ may be broken over the course of 2 years (MD5 using the above data is >2000x), then existing checksums do not stand a significant chance of survival in the future. We should thus accept that whatever checksums we are using today, will be broken in the near future, and plan as best as -possible. (A brief review [H04] of the SHA1 attacks indicates an +possible. (A brief review [H04]_ of the SHA1 attacks indicates an improvement of ~600x in the same timespan). And for those that claim implementation of these procedures is not yet -feasible, see [K06b] for an application that can produce two +feasible, see [K06b]_ for an application that can produce two self-extracting EXE files, with identical MD5s, and whatever payload you want. @@ -91,7 +91,7 @@ The good news Of the checksums presently used by Manifest2 (SHA1, SHA256, RIPEMD160), one stands close to being completely broken: SHA1; and another is significantly weakened: RIPEMD160. The SHA2 series has suffered some -attacks, but still remains reasonably solid [G07],[K08]. +attacks, but still remains reasonably solid [G07]_, [K08]_. To reduce the potential for future problems and any single checksum break leading to a rapid decrease in security, we should incorporate the @@ -111,7 +111,7 @@ as long as the depreciation process is followed (see below). As soon as feasible, we should add the SHA512 and WHIRLPOOL algorithms. In future, as stream-based checksums are developed (in response to the -development by NIST [AHS]), they should be considered and used. +development by NIST [AHS]_), they should be considered and used. The SHA512 algorithm is available in Python 2.5, which has been a dependency of Portage since approximately Portage 2.1.6.13. diff --git a/glep-0060.rst b/glep-0060.rst index 95c672b..7ef6aa2 100644 --- a/glep-0060.rst +++ b/glep-0060.rst @@ -15,12 +15,12 @@ Replaced-By: 74 Abstract ======== -Clarification of the Manifest2 [GLEP44] specification, including new types to -help in the tree-signing specification. +Clarification of the Manifest2 [GLEP44]_ specification, including new +types to help in the tree-signing specification. Motivation ========== -[GLEP44] was not entirely clear on the usage of filetype specifiers. +[GLEP44]_ was not entirely clear on the usage of filetype specifiers. This document serves to provide some of the internal logic used by Portage at the point of writing, as well as adding new types to cover the rest of the tree, for the purposes of tree-signing coverage. @@ -178,7 +178,7 @@ On Bloat If repeated use of a common path prefix is considered a bloat problem, a Manifest file should be added inside the common directory, however this should not be done blindly, as bloat by inodes is more significant for -the majority of use cases. See also [GLEP58] on size reductions of +the majority of use cases. See also [GLEP58]_ on size reductions of Manifests. Chosing a filetype @@ -223,7 +223,7 @@ The new entries may be included already in all Manifest files, as they will be ignored by older Portage versions. Over time, ECLASS, DATA, EXEC, OTHER may replace the existing AUX type. -The adoption of this proposal does also affect [GLEP58] as part of +The adoption of this proposal does also affect [GLEP58]_ as part of this GLEP series, however this GLEP was an offset of the research in that GLEP.