Use relative links in markdown files

Our repository is sometimes copied into other repositories, at which
point all the absolute links don't work. README.md used "./whatever",
which seems to work most consistently, so copy that.

Change-Id: I63bbf01b8f3870112d1df571adaa6cc82f58e5eb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64347
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Hubert Chao <hchao@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
(cherry picked from commit 90004f080d82cb22d643895add1e5740e9a57945)

API-CONVENTIONS.md

@@ -1,7 +1,7 @@
 # BoringSSL API Conventions
 
 This document describes conventions for BoringSSL APIs. The [style
-guide](/STYLE.md) also includes guidelines, but this document is targeted at
+guide](./STYLE.md) also includes guidelines, but this document is targeted at
 both API consumers and developers.
 
 

BUILDING.md

@@ -4,7 +4,7 @@
 
 The standalone CMake build is primarily intended for developers. If embedding
 AWS-LC into another project with a pre-existing build system, see
-[INCORPORATING.md](/INCORPORATING.md).
+[INCORPORATING.md](./INCORPORATING.md).
 
 If in doubt, use the most recent stable version of each build tool.
 

INCORPORATING.md

@@ -1,4 +1,5 @@
 # Incorporating AWS-LC into a project
+
 ## Which branch to use
 
 AWS-LC usage typically follows a
@@ -24,14 +25,14 @@ outside of the CMake environment, these intermediates are generated and
 checked into the AWS-LC source repository in `generated-src`. This avoids
 incorporating projects needing to support Perl and Go in their build systems.
 
-The script [`util/generate_build_files.py`](/util/generate_build_files.py)
+The script [`util/generate_build_files.py`](./util/generate_build_files.py)
 expects to be run from the `aws-lc` directory. The generated build files will 
 be output to `aws-lc/generated-src`. If you don't use any of the supported
 build systems then you should augment `generate_build_files.py` with support
 for it.
 
 The script will pregenerate the intermediate files (see
-[BUILDING.md](/BUILDING.md) for details about which tools will need to be
+[BUILDING.md](./BUILDING.md) for details about which tools will need to be
 installed) and output helper files for that build system. It doesn't generate a
 complete build script, just file and test lists, which change often.
 

SANDBOXING.md

@@ -21,7 +21,7 @@ would be a sandbox escape.
 
 This document attempts to describe these baseline OS dependencies and long-lived
 internal resources. These dependencies may change over time, but we aim to
-[work with sandboxed consumers](/BREAKING-CHANGES.md) when they do. However,
+[work with sandboxed consumers](./BREAKING-CHANGES.md) when they do. However,
 each sandbox imposes different constraints, so, above all, sandboxed consumers
 must have ample test coverage to detect issues as they arise.
 

crypto/fipsmodule/FIPS.md

@@ -8,11 +8,11 @@ Please note that we cannot answer questions about FIPS, nor about using BoringSS
 
 BoringCrypto has undergone the following validations:
 
-1. 2017-06-15: certificate [#2964](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/2964), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Security-Policy-20170615.docx) (in docx format).
-1. 2018-07-30: certificate [#3318](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3318), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Security-Policy-20180730.docx) (in docx format).
-1. 2019-08-08: certificate [#3678](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3678), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Security-Policy-20190808.docx) (in docx format).
-1. 2019-10-20: certificate [#3753](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3753), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Android-Security-Policy-20191020.docx) (in docx format).
-1. 2021-01-28: certificate [#4156](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/4156), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Android-Security-Policy-20210319.docx) (in docx format).
+1. 2017-06-15: certificate [#2964](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/2964), [security policy](./policydocs/BoringCrypto-Security-Policy-20170615.docx) (in docx format).
+1. 2018-07-30: certificate [#3318](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3318), [security policy](./policydocs/BoringCrypto-Security-Policy-20180730.docx) (in docx format).
+1. 2019-08-08: certificate [#3678](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3678), [security policy](./policydocs/BoringCrypto-Security-Policy-20190808.docx) (in docx format).
+1. 2019-10-20: certificate [#3753](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3753), [security policy](./policydocs/BoringCrypto-Android-Security-Policy-20191020.docx) (in docx format).
+1. 2021-01-28: certificate [#4156](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/4156), [security policy](./policydocs/BoringCrypto-Android-Security-Policy-20210319.docx) (in docx format).
 1. 2021-04-29: certificate [#4407](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4407).
 
 ## Running ACVP tests
@@ -120,7 +120,7 @@ The most obvious cause of relocations are out-calls from the module to non-crypt
 
 Offsets to these functions cannot be known until the final link because only the linker sees the object files containing them. Thus calls to these functions are rewritten into an IP-relative jump to a redirector function. The redirector functions contain a single jump instruction to the real function and are placed outside of the module and are thus not hashed (see diagram).
 
-![module structure](/crypto/fipsmodule/intcheck1.png)
+![module structure](./intcheck1.png)
 
 In this diagram, the integrity check hashes from `module_start` to `module_end`. Since this does not cover the jump to `memcpy`, it's fine that the linker will poke the final offset into that instruction.
 
@@ -152,7 +152,7 @@ In order to actually implement the integrity test, a constructor function within
 
 Initially the known-good value will be incorrect. Another script (`inject_hash.go`) calculates the correct value from the assembled object and injects it back into the object.
 
-![build process](/crypto/fipsmodule/intcheck2.png)
+![build process](./intcheck2.png)
 
 ### Comparison with OpenSSL's method
 
@@ -172,4 +172,4 @@ Some of the similarities are worth noting:
 
 1.  OpenSSL has all out-calls from the module indirecting via the PLT, which is equivalent to the redirector functions described above.
 
-![OpenSSL build process](/crypto/fipsmodule/intcheck3.png)
+![OpenSSL build process](./intcheck3.png)