Update references to master branch with main branch (#2169)

.github/workflows/private_sync.yml

@@ -2,7 +2,6 @@ name: force_push
 on:
   push:
     branches:
-      - master
       - main
 jobs:
   build:

README.md

@@ -2,11 +2,11 @@
 
 s2n is a C99 implementation of the TLS/SSL protocols that is designed to be simple, small, fast, and with security as a priority. It is released and licensed under the Apache License 2.0. 
 
-[![Build Status](https://codebuild.us-west-2.amazonaws.com/badges?uuid=eyJlbmNyeXB0ZWREYXRhIjoiQkcyWjA5cThqZHF3ZGR4enpYN1V4RlAwdnl3Rzk1a2lUNzB5S0JHNUxreTRLUEthbHRaZjJ0M0kvLzJrK3U3SmhtVEhOVG9qMlowenhDWXZWWnFhMU53PSIsIml2UGFyYW1ldGVyU3BlYyI6IldNeTdSak5VZ1M1WjlZRVEiLCJtYXRlcmlhbFNldFNlcmlhbCI6MX0%3D&branch=master)](https://github.com/awslabs/s2n/)
+[![Build Status](https://codebuild.us-west-2.amazonaws.com/badges?uuid=eyJlbmNyeXB0ZWREYXRhIjoiMndlTzJNbHVxWEo3Nm82alp4eGdGNm4rTWdxZDVYU2VTbitIR0ZLbHVtcFFGOW5majk5QnhqaUp3ZEkydG1ueWg0NGlhRE43a1ZnUzZaQTVnSm91TzFFPSIsIml2UGFyYW1ldGVyU3BlYyI6IlJLbW42NENlYXhJNy80QnYiLCJtYXRlcmlhbFNldFNlcmlhbCI6MX0%3D&branch=main)](https://github.com/awslabs/s2n/)
 [![Apache 2 License](https://img.shields.io/github/license/awslabs/s2n.svg)](http://aws.amazon.com/apache-2-0/)
 [![C99](https://img.shields.io/badge/language-C99-blue.svg)](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)
 [![Language grade: C/C++](https://img.shields.io/lgtm/grade/cpp/g/awslabs/s2n.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/awslabs/s2n/context:cpp)
-[![codecov](https://codecov.io/gh/awslabs/s2n/branch/master/graph/badge.svg)](https://codecov.io/gh/awslabs/s2n)
+[![codecov](https://codecov.io/gh/awslabs/s2n/branch/main/graph/badge.svg)](https://codecov.io/gh/awslabs/s2n)
 [![Github forks](https://img.shields.io/github/forks/awslabs/s2n.svg)](https://github.com/awslabs/s2n/network)
 [![Github stars](https://img.shields.io/github/stars/awslabs/s2n.svg)](https://github.com/awslabs/s2n/stargazers)
 [![Join the chat at https://gitter.im/awslabs/s2n](https://badges.gitter.im/awslabs/s2n.svg)](https://gitter.im/awslabs/s2n?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
@@ -81,7 +81,7 @@ int bytes_written;
 bytes_written = s2n_send(conn, "Hello World", sizeof("Hello World"), &blocked);
 ```
 
-For details on building the s2n library and how to use s2n in an application you are developing, see the [API Reference](https://github.com/awslabs/s2n/blob/master/docs/USAGE-GUIDE.md).
+For details on building the s2n library and how to use s2n in an application you are developing, see the [API Reference](https://github.com/awslabs/s2n/blob/main/docs/USAGE-GUIDE.md).
 
 ## s2n features
 
@@ -145,7 +145,7 @@ AWS Security via our [vulnerability reporting page](http://aws.amazon.com/securi
 If you package or distribute s2n, or use s2n as part of a large multi-user service, you may be eligible for pre-notification of future s2n releases. Please contact s2n-pre-notification@amazon.com.  
 
 ## Contributing to s2n
-If you are interested in contributing to s2n, please see our [development guide](https://github.com/awslabs/s2n/blob/master/docs/DEVELOPMENT-GUIDE.md).
+If you are interested in contributing to s2n, please see our [development guide](https://github.com/awslabs/s2n/blob/main/docs/DEVELOPMENT-GUIDE.md).
 
 ## Language Bindings for s2n
-See our [language bindings list](https://github.com/awslabs/s2n/blob/master/docs/BINDINGS.md) for language bindings for s2n that we're aware of. 
+See our [language bindings list](https://github.com/awslabs/s2n/blob/main/docs/BINDINGS.md) for language bindings for s2n that we're aware of. 

docs/DEVELOPMENT-GUIDE.md

@@ -2,7 +2,7 @@
 
 If you are curious about the internals of s2n, or interested in contributing to
 s2n, this document is for you. If instead you are interested in using s2n in an application
-that you are developing, please see the accompanying [Usage Guide](https://github.com/awslabs/s2n/blob/master/docs/USAGE-GUIDE.md).
+that you are developing, please see the accompanying [Usage Guide](https://github.com/awslabs/s2n/blob/main/docs/USAGE-GUIDE.md).
 
 ## s2n's development principles
 
@@ -91,7 +91,7 @@ benefit is that functions can read quite declaratively. In the case of message
 parsers, the function contents can read almost like schemas of the message
 being parsed.
 
-A good example file for message parsing to look at is [tls/s2n_server_finished.c](https://github.com/awslabs/s2n/blob/master/tls/s2n_server_finished.c).
+A good example file for message parsing to look at is [tls/s2n_server_finished.c](https://github.com/awslabs/s2n/blob/main/tls/s2n_server_finished.c).
 From reading the file it should be reasonably clear that a server
 finished message consists just of S2N_TLS_FINISHED_LEN number of bytes, what
 the next state is and so on.
@@ -113,7 +113,7 @@ if (s2n_result_is_error(s2n_do_something(with_something_else))) {
 }
 ```
 
-is so common that [utils/s2n_safety.h](https://github.com/awslabs/s2n/blob/master/utils/s2n_safety.h) provides several macros for working with fallible functions. Notable macros include;
+is so common that [utils/s2n_safety.h](https://github.com/awslabs/s2n/blob/main/utils/s2n_safety.h) provides several macros for working with fallible functions. Notable macros include;
 
 ```c
 /**
@@ -130,7 +130,7 @@ is so common that [utils/s2n_safety.h](https://github.com/awslabs/s2n/blob/maste
 These macros should be used when calling functions you expect to succeed. Primarily these macros help save two lines that repeatedly clutter files, and secondarily they are very useful when developing and debugging code as it is easy to redefine the macro to implement a simple backtrace (even a simple printf will suffice, but a breakpoint is more usual).
 
 If a function does fail, it should use the `BAIL(errno)` macro provided for surfacing the error to an application.
-New error translations, and their human-readable translations can be defined in [error/s2n_errno.h](https://github.com/awslabs/s2n/blob/master/error/s2n_errno.h) and [error/s2n_errno.c](https://github.com/awslabs/s2n/blob/master/error/s2n_errno.c). When called, e.g.:
+New error translations, and their human-readable translations can be defined in [error/s2n_errno.h](https://github.com/awslabs/s2n/blob/main/error/s2n_errno.h) and [error/s2n_errno.c](https://github.com/awslabs/s2n/blob/main/error/s2n_errno.c). When called, e.g.:
 
 ```c
 BAIL(S2N_ERR_BAD_MESSAGE);
@@ -140,7 +140,7 @@ the macro will set s2n_errno correctly, as well as some useful debug strings, an
 
 ### Safety checking
 
-[utils/s2n_safety.h](https://github.com/awslabs/s2n/blob/master/utils/s2n_safety.h) provides several more convenience macros intended to make safety and bounds checking easier. There are checked versions of memcpy (`CHECKED_MEMCPY`) and memset (`CHECKED_MEMSET`), as well as predicate testers like `ENSURE`, `ENSURE_GTE`, `ENSURE_INCLUSIVE_RANGE`, `ENSURE_EXCLUSIVE_RANGE` for performing simple comparisons in a systematic, error-handled, way.
+[utils/s2n_safety.h](https://github.com/awslabs/s2n/blob/main/utils/s2n_safety.h) provides several more convenience macros intended to make safety and bounds checking easier. There are checked versions of memcpy (`CHECKED_MEMCPY`) and memset (`CHECKED_MEMSET`), as well as predicate testers like `ENSURE`, `ENSURE_GTE`, `ENSURE_INCLUSIVE_RANGE`, `ENSURE_EXCLUSIVE_RANGE` for performing simple comparisons in a systematic, error-handled, way.
 
 *Note*: In general, C preprocessor Macros with embedded control flow are a bad idea, but `GUARD`, `ENSURE`, and `BAIL` are so thoroughly used throughout s2n that it should be a clear and idiomatic pattern, almost forming a small domain specific language.
 
@@ -167,7 +167,7 @@ As discussed below, s2n rarely allocates resources, and so has nothing to clean
 
 Branches can be a source of cognitive load, as they ask the reader to follow a path of thinking, while also remembering that there is another path to be explored. When branches are nested, they can often lead to impossible to grasp combinatorial explosions. s2n tries to systematically reduce the number of branches used in the code in several ways.
 
-Firstly, there are almost no ifdef calls in s2n. Ifdefs can be a particularly penalizing source of cognitive load. In addition to being a branch, they also ask the reader to mix state from two different languages (C, and the C preprocessor) and they tend to be associated with ugly rendering in IDEs and code formatters. In the few places where ifdef's are necessary, we use them in a careful way without compromising the integrity of the function. [tls/s2n_config.c](https://github.com/awslabs/s2n/blob/master/tls/s2n_config.c) is a good example. Rather than mixing the Apple and non-Apple implementations and cluttering one function with several ifdefs, there is a complete implementation of the timer functionality for each platform. Within the POSIX implementation, an ifdef and define are used to use the most precise clock type, but in a way that does not compromise readability.
+Firstly, there are almost no ifdef calls in s2n. Ifdefs can be a particularly penalizing source of cognitive load. In addition to being a branch, they also ask the reader to mix state from two different languages (C, and the C preprocessor) and they tend to be associated with ugly rendering in IDEs and code formatters. In the few places where ifdef's are necessary, we use them in a careful way without compromising the integrity of the function. [tls/s2n_config.c](https://github.com/awslabs/s2n/blob/main/tls/s2n_config.c) is a good example. Rather than mixing the Apple and non-Apple implementations and cluttering one function with several ifdefs, there is a complete implementation of the timer functionality for each platform. Within the POSIX implementation, an ifdef and define are used to use the most precise clock type, but in a way that does not compromise readability.
 
 Secondly, s2n generally branches in the case of failure, rather than success. So instead of creating a nest of if's:
 
@@ -217,15 +217,15 @@ There is also a brief set of other coding conventions:
 
 s2n is written in C99, a language which lacks a "standard" testing framework. Although there are some more well used C++ testing frameworks, s2n also targets some embedded platforms on which a C++ compiler is unavailable.
 
-Since testing and test-cases are absolutely mandatory for all s2n functionality, s2n includes its own small testing framework, defined in [tests/s2n_test.h](https://github.com/awslabs/s2n/blob/master/tests/s2n_test.h). The framework consists of 15 macros that allow you to start a test suite, which is a normal C application with a main() function, and to validate various expectations.
+Since testing and test-cases are absolutely mandatory for all s2n functionality, s2n includes its own small testing framework, defined in [tests/s2n_test.h](https://github.com/awslabs/s2n/blob/main/tests/s2n_test.h). The framework consists of 15 macros that allow you to start a test suite, which is a normal C application with a main() function, and to validate various expectations.
 
-Unit tests are added as .c files in [tests/unit/](https://github.com/awslabs/s2n/blob/master/tests/unit/). A simple example to look at is [tests/unit/s2n_stuffer_base64_test.c](https://github.com/awslabs/s2n/blob/master/tests/unit/s2n_stuffer_base64_test.c). The tests are started with BEGIN_TEST(), and expectations are tested with EXPECT_SUCCESS and EXPECT_EQUAL before exiting with an END_TEST call.
+Unit tests are added as .c files in [tests/unit/](https://github.com/awslabs/s2n/blob/main/tests/unit/). A simple example to look at is [tests/unit/s2n_stuffer_base64_test.c](https://github.com/awslabs/s2n/blob/main/tests/unit/s2n_stuffer_base64_test.c). The tests are started with BEGIN_TEST(), and expectations are tested with EXPECT_SUCCESS and EXPECT_EQUAL before exiting with an END_TEST call.
 
 The test framework will take care of compiling and executing the tests and indicates success or failure with green or red text in the console.
 
 In addition to fully covering functionality in the correct cases, s2n tests are also expected to include adversarial or "negative" test cases. For example, the tests performed on record encryption validate that s2n is tamper resistant by attempting to actually tamper with records. Similarly, we validate that our memory handling routines cannot be over-filled by attempting to over-fill them.
 
-To avoid adding unneeded code to the production build of s2n, there is also a small test library defined at [tests/testlib/](https://github.com/awslabs/s2n/blob/master/tests/testlib/) which includes routines useful for test cases. For example, there is a hex parser and emitter, which is useful for defining network data in test cases, but not needed in production.
+To avoid adding unneeded code to the production build of s2n, there is also a small test library defined at [tests/testlib/](https://github.com/awslabs/s2n/blob/main/tests/testlib/) which includes routines useful for test cases. For example, there is a hex parser and emitter, which is useful for defining network data in test cases, but not needed in production.
 
 Unit tests are run automatically with `make`. To run a subset of the unit tests, set the `UNIT_TESTS` environment variable with the unit test name(s). For example:
 ```
@@ -247,7 +247,7 @@ struct s2n_blob {
 };
 ```
 
-Functions that handle memory ranges are expected to at least use blobs (stuffers are better though, as we'll see). A blob can be initialized with an existing memory buffer using **s2n_blob_init**, but  [utils/s2n_mem.h](https://github.com/awslabs/s2n/blob/master/utils/s2n_mem.h) also defines routines for dynamically allocated blobs. For handling user data, we prefer the latter, as s2n prevents the memory regions from being swapped to disk and from showing up in core files (where supported).
+Functions that handle memory ranges are expected to at least use blobs (stuffers are better though, as we'll see). A blob can be initialized with an existing memory buffer using **s2n_blob_init**, but  [utils/s2n_mem.h](https://github.com/awslabs/s2n/blob/main/utils/s2n_mem.h) also defines routines for dynamically allocated blobs. For handling user data, we prefer the latter, as s2n prevents the memory regions from being swapped to disk and from showing up in core files (where supported).
 
 ### s2n_stuffer: a streaming buffer
 
@@ -358,7 +358,7 @@ Every connection is associated with an s2n_connection structure. The details of
 
 When a TLS connection is being started, the first communication consists of handshake messages. The client sends the first message (a client hello), and then the server replies (with a server hello), and so on. Because a server must wait for a client and vice versa, this phase of a TLS connection is not full-duplex. To save on memory, s2n uses a single stuffer for both incoming and outgoing handshake messages and it is located as s2n_connection->handshake.io (which is a growable stuffer).
 
-Borrowing another trick from functional programming, the state machine for handling handshake messages is implemented using a table of function pointers, located in [tls/s2n_handshake_io.c](https://github.com/awslabs/s2n/blob/master/tls/s2n_handshake_io.c).
+Borrowing another trick from functional programming, the state machine for handling handshake messages is implemented using a table of function pointers, located in [tls/s2n_handshake_io.c](https://github.com/awslabs/s2n/blob/main/tls/s2n_handshake_io.c).
 
 ```c
 static struct s2n_handshake_action state_machine[] = {
@@ -386,7 +386,7 @@ One detail we've skipped over so far is that handshake messages are encapsulated
 
 ![TLS layers](images/s2n_tls_layers.png "s2n TLS layers")
 
-In the outbound direction, s2n never coalesces multiple messages into a single record, so writing a handshake message is a simple matter of fragmenting the handshake message if necessary and writing the records. In the inbound direction, the small state machine in s2n_handshake_io.c takes care of any fragmentation and coalescing. See [tests/unit/s2n_fragmentation_coalescing_test.c](https://github.com/awslabs/s2n/blob/master/tests/unit/s2n_fragmentation_coalescing_test.c) for our test cases covering the logic too.
+In the outbound direction, s2n never coalesces multiple messages into a single record, so writing a handshake message is a simple matter of fragmenting the handshake message if necessary and writing the records. In the inbound direction, the small state machine in s2n_handshake_io.c takes care of any fragmentation and coalescing. See [tests/unit/s2n_fragmentation_coalescing_test.c](https://github.com/awslabs/s2n/blob/main/tests/unit/s2n_fragmentation_coalescing_test.c) for our test cases covering the logic too.
 
 To perform all of this, the s2n_connection structure has a few more internal stuffers:
 

docs/USAGE-GUIDE.md

@@ -1753,6 +1753,6 @@ function that can free memory.
 
 # Examples
 
-To understand the API it may be easiest to see examples in action. s2n's [bin/](https://github.com/awslabs/s2n/blob/master/bin/) directory
+To understand the API it may be easiest to see examples in action. s2n's [bin/](https://github.com/awslabs/s2n/blob/main/bin/) directory
 includes an example client (s2nc) and server (s2nd).
 

error/s2n_errno.c

@@ -372,7 +372,7 @@ int s2n_print_stacktrace(FILE *fptr)
     if (!s_s2n_stack_traces_enabled) {
       fprintf(fptr, "%s\n%s\n",
 	      "NOTE: Some details are omitted, run with S2N_PRINT_STACKTRACE=1 for a verbose backtrace.",
-	      "See https://github.com/awslabs/s2n/blob/master/docs/USAGE-GUIDE.md");
+	      "See https://github.com/awslabs/s2n/blob/main/docs/USAGE-GUIDE.md");
         return S2N_SUCCESS;
     }
 

libcrypto-build/README.md

@@ -1,4 +1,4 @@
 This directory is used to store build artifacts (tarballs and source) for a locally
 built copy of libcrypto, either from OpenSSL, LibreSSL or BoringSSL.
 
-See the s2n [Usage Guide](https://github.com/awslabs/s2n/blob/master/docs/USAGE-GUIDE.md) for more details.
+See the s2n [Usage Guide](https://github.com/awslabs/s2n/blob/main/docs/USAGE-GUIDE.md) for more details.

pq-crypto/README.md

@@ -28,19 +28,19 @@ defines hybrid group values for interoperability.
 ## SIKE (Supersingular Isogeny Key Encapsulation)
 The code in the pq-crypto/sike_r1 directory was taken from the [round 1 NIST submission](https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/round-1/submissions/SIKE.zip).
 s2n uses the optimized portable implementation to ensure maximum comparability and ease of review. The known answer tests
-are [here](https://github.com/awslabs/s2n/blob/master/tests/unit/s2n_sike_r1_kat_test.c) and use the known answer file
+are [here](https://github.com/awslabs/s2n/blob/main/tests/unit/s2n_sike_r1_kat_test.c) and use the known answer file
 from the SIKEp503 round 1 submission.
 
 The code in the pq-crypto/sike_r2 directory was imported from [liboqs](https://github.com/open-quantum-safe/liboqs/tree/386372ba7dbef781f0b939f1cf73d33019958d6a/src/kem/sike), and
 implements the [round 2 NIST submission](https://csrc.nist.gov/projects/post-quantum-cryptography/round-2-submissions). s2n is configured to use the optimized
 assembly implementation on x86_64 processors, and the optimized portable implementation elsewhere. The known answer tests
-are [here](https://github.com/awslabs/s2n/blob/master/tests/unit/s2n_sike_r2_kat_test.c) and use the known answer file from the SIKEP434 round 2 submission.
+are [here](https://github.com/awslabs/s2n/blob/main/tests/unit/s2n_sike_r2_kat_test.c) and use the known answer file from the SIKEP434 round 2 submission.
 
 ## BIKE (Bit Flipping Key Encapsulation)
 The code in the pq-crypto/bike directory was taken from the [additional implementation](https://bikesuite.org/files/round2/add-impl/Additional_Implementation.2019.03.30.zip).
 s2n uses the "additional implementation" which ensures constant time primitives, does not use any external libraries
 besides libcrypto, and does not depend on any specific hardware instructions to ensure maximum comparability and ease of
-review. The known answer tests are [here](https://github.com/awslabs/s2n/blob/master/tests/unit/s2n_bike1_l1_r1_kat_test.c)
+review. The known answer tests are [here](https://github.com/awslabs/s2n/blob/main/tests/unit/s2n_bike1_l1_r1_kat_test.c)
 and use the BIKE1_L1.const.kat from the above Additional_Implementation.2019.03.30.zip. This implementation uses constant
 time primitives on x86 and aarch64 platforms.