update main-with-bazel from main branch

.github/PULL_REQUEST_TEMPLATE

@@ -2,6 +2,6 @@ Please do not send pull requests to the BoringSSL repository.
 
 We do, however, take contributions gladly.
 
-See https://boringssl.googlesource.com/boringssl/+/master/CONTRIBUTING.md
+See https://boringssl.googlesource.com/boringssl/+/main/CONTRIBUTING.md
 
 Thanks!

src/BREAKING-CHANGES.md

@@ -36,7 +36,7 @@ In most cases, this is straightforward:
 
 The removal should still include an `Update-Note` tag, in case some were missed.
 
-In some cases, this kind of staged approach is not feasible: perhaps the same code cannot simultaneously work before and after the change, or perhaps there are too many different versions in play. For instance, [Conscrypt](https://github.com/google/conscrypt) feeds into three different repositories. The GitHub repository consumes BoringSSL's `master` branch directly. It is pushed into Android, where it consumes Android's `external/boringssl`. Yet another copy is pushed into the internal repository, where it consumes that copy of BoringSSL. As each of these Conscrypts are updated independently from their corresponding BoringSSLs, Conscrypt upstream cannot rely on a new BoringSSL API until it is present in all copies of BoringSSL its downstreams rely on.
+In some cases, this kind of staged approach is not feasible: perhaps the same code cannot simultaneously work before and after the change, or perhaps there are too many different versions in play. For instance, [Conscrypt](https://github.com/google/conscrypt) feeds into three different repositories. The GitHub repository consumes BoringSSL's `main` branch directly. It is pushed into Android, where it consumes Android's `external/boringssl`. Yet another copy is pushed into the internal repository, where it consumes that copy of BoringSSL. As each of these Conscrypts are updated independently from their corresponding BoringSSLs, Conscrypt upstream cannot rely on a new BoringSSL API until it is present in all copies of BoringSSL its downstreams rely on.
 
 In that case, a multi-sided change may be more appropriate:
 

src/CONTRIBUTING.md

@@ -33,9 +33,9 @@ on commit. Run:
     chmod u+x .git/hooks/commit-msg
 
 #### Uploading changes
-To upload a change, push it to the special `refs/for/master` target:
+To upload a change, push it to the special `refs/for/main` target:
 
-    git push origin HEAD:refs/for/master
+    git push origin HEAD:refs/for/main
 
 The output will then give you a link to the change. Add `agl@google.com`,
 `davidben@google.com`, and `bbe@google.com` as reviewers.

src/INCORPORATING.md

@@ -67,7 +67,7 @@ top-level build logic, maintained by the embedder.
 
 Source lists for various build systems are pre-generated and live in the `gen`
 directory. For example, source lists for
-[GN](https://gn.googlesource.com/gn/+/master/docs/quick_start.md) live in
+[GN](https://gn.googlesource.com/gn/+/main/docs/quick_start.md) live in
 [gen/sources.gni](./gen/sources.gni). There is also a generic
 [gen/sources.json](./gen/sources.json) file for projects to consume if needed.
 [util/build/build.go](./util/build/build.go) describes what the various source

src/crypto/fipsmodule/sha/asm/sha256-armv4.pl

@@ -485,7 +485,7 @@ sha256_block_data_order_neon:
 	@ TODO(davidben): adrl would avoid a load, but clang-assembler does not
 	@ support it. We might be able to emulate it with a macro, but Android's
 	@ did not work when I tried it.
-	@ https://android.googlesource.com/platform/ndk/+/refs/heads/master/docs/ClangMigration.md#arm
+	@ https://android.googlesource.com/platform/ndk/+/refs/heads/main/docs/ClangMigration.md#arm
 	ldr	$Ktbl,.LK256_shortcut_neon
 .LK256_add_neon:
 	add	$Ktbl,pc,$Ktbl

src/crypto/trust_token/trust_token.cc

@@ -23,7 +23,7 @@
 
 
 // The Trust Token API is described in
-// https://github.com/WICG/trust-token-api/blob/master/README.md and provides a
+// https://github.com/WICG/trust-token-api/blob/main/README.md and provides a
 // protocol for issuing and redeeming tokens built on top of the PMBTokens
 // construction.
 

src/gen/bcm/sha256-armv4-linux.S

@@ -1893,7 +1893,7 @@ sha256_block_data_order_neon:
 	@ TODO(davidben): adrl would avoid a load, but clang-assembler does not
 	@ support it. We might be able to emulate it with a macro, but Android's
 	@ did not work when I tried it.
-	@ https://android.googlesource.com/platform/ndk/+/refs/heads/master/docs/ClangMigration.md#arm
+	@ https://android.googlesource.com/platform/ndk/+/refs/heads/main/docs/ClangMigration.md#arm
 	ldr	r14,.LK256_shortcut_neon
 .LK256_add_neon:
 	add	r14,pc,r14

src/include/openssl/asm_base.h

@@ -152,7 +152,7 @@
 //
 // References:
 // - "ELF for the Arm® 64-bit Architecture"
-//   https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst
+//   https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst
 // - "Providing protection for complex software"
 //   https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software
 

src/include/openssl/ssl.h

@@ -1782,10 +1782,11 @@ OPENSSL_EXPORT int SSL_session_reused(const SSL *ssl);
 // renegotiation (RFC 5746) or TLS 1.3. Otherwise, it returns zero.
 OPENSSL_EXPORT int SSL_get_secure_renegotiation_support(const SSL *ssl);
 
-// SSL_export_keying_material exports a value derived from the master secret, as
-// specified in RFC 5705. It writes |out_len| bytes to |out| given a label and
-// optional context. (Since a zero length context is allowed, the |use_context|
-// flag controls whether a context is included.)
+// SSL_export_keying_material exports a connection-specific secret from |ssl|,
+// as specified in RFC 5705. It writes |out_len| bytes to |out| given a label
+// and optional context. If |use_context| is zero, the |context| parameter is
+// ignored. Prior to TLS 1.3, using a zero-length context and using no context
+// would give different output.
 //
 // It returns one on success and zero otherwise.
 OPENSSL_EXPORT int SSL_export_keying_material(
@@ -5604,7 +5605,7 @@ OPENSSL_EXPORT enum ssl_compliance_policy_t SSL_get_compliance_policy(
 //
 // See PORTING.md in the BoringSSL source tree for a table of corresponding
 // functions.
-// https://boringssl.googlesource.com/boringssl/+/master/PORTING.md#Replacements-for-values
+// https://boringssl.googlesource.com/boringssl/+/main/PORTING.md#Replacements-for-values
 
 #define DTLS_CTRL_GET_TIMEOUT doesnt_exist
 #define DTLS_CTRL_HANDLE_TIMEOUT doesnt_exist

src/include/openssl/trust_token.h

@@ -31,8 +31,8 @@ extern "C" {
 //
 // References:
 // https://eprint.iacr.org/2020/072.pdf
-// https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts
-// https://github.com/WICG/trust-token-api/blob/master/README.md
+// https://github.com/ietf-wg-privacypass/base-drafts
+// https://github.com/WICG/trust-token-api/blob/main/README.md
 //
 // WARNING: This API is unstable and subject to change.
 

src/ssl/test/PORTING.md

@@ -8,7 +8,7 @@ BoringSSL and some incomplete integrations with NSS and OpenSSL.
 
 Note that supporting non-BoringSSL implementations is a work in
 progress and interfaces may change in the future. Consumers should pin
-to a particular revision rather than using BoringSSL’s master branch
+to a particular revision rather than using BoringSSL’s `main` branch
 directly. As we gain experience with other implementations, we hope to
 make further improvements to portability, so please contact
 davidben@google.com and ekr@rtfm.com if implementing a new shim.

src/util/testresult/testresult.go

@@ -13,7 +13,7 @@
  * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
 
 // testresult is an implementation of Chromium's JSON test result format. See
-// https://chromium.googlesource.com/chromium/src/+/master/docs/testing/json_test_results_format.md
+// https://chromium.googlesource.com/chromium/src/+/main/docs/testing/json_test_results_format.md
 package testresult
 
 import (