glep-{0057,0058,0059,0060}: Fix syntax of cross references.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>

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.