master -> main (envoyproxy#14729)

Various fixes

Signed-off-by: Matt Klein <[email protected]>

.azure-pipelines/cve_scan.yml

@@ -9,7 +9,7 @@ schedules:
   displayName: Hourly CVE scan
   branches:
     include:
-    - master
+    - main
   always: true
 
 pool:

.azure-pipelines/pipelines.yml

@@ -1,7 +1,7 @@
 trigger:
   branches:
     include:
-      - "master"
+      - "main"
       - "release/v*"
   tags:
     include:

.bazelrc

@@ -245,7 +245,7 @@ build:remote-clang-cl --config=clang-cl
 build:remote-clang-cl --config=rbe-toolchain-clang-cl
 
 # Docker sandbox
-# NOTE: Update this from https://github.com/envoyproxy/envoy-build-tools/blob/master/toolchains/rbe_toolchains_config.bzl#L8
+# NOTE: Update this from https://github.com/envoyproxy/envoy-build-tools/blob/main/toolchains/rbe_toolchains_config.bzl#L8
 build:docker-sandbox --experimental_docker_image=envoyproxy/envoy-build-ubuntu:11efa5680d987fff33fde4af3cc5ece105015d04
 build:docker-sandbox --spawn_strategy=docker
 build:docker-sandbox --strategy=Javac=docker

.github/ISSUE_TEMPLATE/non--crash-security--bug.md

@@ -22,7 +22,7 @@ returned, etc.
 > Include sample requests, environment, etc. All data and inputs
 required to reproduce the bug.
 
->**Note**: The [Envoy_collect tool](https://github.com/envoyproxy/envoy/blob/master/tools/envoy_collect/README.md)
+>**Note**: The [Envoy_collect tool](https://github.com/envoyproxy/envoy/blob/main/tools/envoy_collect/README.md)
 gathers a tarball with debug logs, config and the following admin
 endpoints: /stats, /clusters and /server_info. Please note if there are
 privacy concerns, sanitize the data prior to sharing the tarball/pasting.
@@ -46,4 +46,4 @@ sharing.
 
 *Call Stack*:
 > If the Envoy binary is crashing, a call stack is **required**.
-Please refer to the [Bazel Stack trace documentation](https://github.com/envoyproxy/envoy/tree/master/bazel#stack-trace-symbol-resolution).
+Please refer to the [Bazel Stack trace documentation](https://github.com/envoyproxy/envoy/tree/main/bazel#stack-trace-symbol-resolution).

.github/workflows/get_build_targets.sh

@@ -6,7 +6,7 @@ readonly SEARCH_FOLDER="//source/common/..."
 set -e -o pipefail
 
 function get_targets() {
-  # Comparing the PR HEAD with the upstream master HEAD.
+  # Comparing the PR HEAD with the upstream main HEAD.
   git diff --name-only HEAD FETCH_HEAD | while IFS= read -r line
   do
     # Only targets under those folders.
@@ -23,6 +23,6 @@ function get_targets() {
 }
 
 # Fetching the upstream HEAD to compare with and stored in FETCH_HEAD.
-git fetch https://github.com/envoyproxy/envoy.git master 2>/dev/null
+git fetch https://github.com/envoyproxy/envoy.git main 2>/dev/null
 
 export BUILD_TARGETS_LOCAL=$(echo $(get_targets))

CONTRIBUTING.md

@@ -47,7 +47,7 @@ versioning guidelines:
 
 * Features may be marked as deprecated in a given versioned API at any point in time, but this may
   only be done when a replacement implementation and configuration path is available in Envoy on
-  master. Deprecators must implement a conversion from the deprecated configuration to the latest
+  main. Deprecators must implement a conversion from the deprecated configuration to the latest
   `vNalpha` (with the deprecated field) that Envoy uses internally. A field may be deprecated if
   this tool would be able to perform the conversion. For example, removing a field to describe
   HTTP/2 window settings is valid if a more comprehensive HTTP/2 protocol options field is being
@@ -73,7 +73,7 @@ versioning guidelines:
   `envoy.features.enable_all_deprecated_features` is set to true. Finally, following the deprecation
   of the API major version where the field was first marked deprecated, the entire implementation
   code will be removed from the Envoy implementation.
-* This policy means that organizations deploying master should have some time to get ready for
+* This policy means that organizations deploying main should have some time to get ready for
   breaking changes at the next major API version. This is typically a window of at least 12 months
   or until the organization moves to the next major API version.
 * The breaking change policy also applies to source level extensions (e.g., filters). Code that
@@ -144,7 +144,7 @@ versioning guidelines:
 * If your PR involves any changes to
   [envoy-filter-example](https://github.com/envoyproxy/envoy-filter-example) (for example making a new
   branch so that CI can pass) it is your responsibility to follow through with merging those
-  changes back to master once the CI dance is done.
+  changes back to main once the CI dance is done.
 * If your PR is a high risk change, the reviewer may ask that you runtime guard
   it. See the section on runtime guarding below.
 
@@ -189,18 +189,18 @@ maintainer's discretion. Generally all runtime guarded features will be set true
 release is cut. Old code paths for refactors can be cleaned up after a release and there has been
 some production run time. Old code for behavioral changes will be deprecated after six months.
 Runtime features are set true by default by inclusion in
-[source/common/runtime/runtime_features.cc](https://github.com/envoyproxy/envoy/blob/master/source/common/runtime/runtime_features.cc)
+[source/common/runtime/runtime_features.cc](https://github.com/envoyproxy/envoy/blob/main/source/common/runtime/runtime_features.cc)
 
 There are four suggested options for testing new runtime features:
 
-1. Create a per-test Runtime::LoaderSingleton as done in [DeprecatedFieldsTest.IndividualFieldDisallowedWithRuntimeOverride](https://github.com/envoyproxy/envoy/blob/master/test/common/protobuf/utility_test.cc)
+1. Create a per-test Runtime::LoaderSingleton as done in [DeprecatedFieldsTest.IndividualFieldDisallowedWithRuntimeOverride](https://github.com/envoyproxy/envoy/blob/main/test/common/protobuf/utility_test.cc)
 2. Create a [parameterized test](https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#how-to-write-value-parameterized-tests)
    where the set up of the test sets the new runtime value explicitly to
    GetParam() as outlined in (1).
 3. Set up integration tests with custom runtime defaults as documented in the
-   [integration test README](https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md)
+   [integration test README](https://github.com/envoyproxy/envoy/blob/main/test/integration/README.md)
 4. Run a given unit test with the new runtime value explicitly set true or false as done
-   for [runtime_flag_override_test](https://github.com/envoyproxy/envoy/blob/master/test/common/runtime/BUILD)
+   for [runtime_flag_override_test](https://github.com/envoyproxy/envoy/blob/main/test/common/runtime/BUILD)
 
 Runtime code is held to the same standard as regular Envoy code, so both the old
 path and the new should have 100% coverage both with the feature defaulting true

DEPENDENCY_POLICY.md

@@ -40,7 +40,7 @@ Dependency declarations must:
   and `urls` to reference the version. If you need to reference version `X.Y.Z` as `X_Y_Z`, this
   may appear in a string as `{underscore_version}`, similarly for `X-Y-Z` you can use
   `{dash_version}`.
-* Versions should prefer release versions over master branch GitHub SHA tarballs. A comment is
+* Versions should prefer release versions over main branch GitHub SHA tarballs. A comment is
   necessary if the latter is used. This comment should contain the reason that a non-release
   version is being used.
 * Provide accurate entries for `use_category`. Please think carefully about whether there are data
@@ -112,7 +112,7 @@ basis:
 
 * Extension [CODEOWNERS](CODEOWNERS) should update extension specific dependencies.
 
-Where possible, we prefer the latest release version for external dependencies, rather than master
+Where possible, we prefer the latest release version for external dependencies, rather than main
 branch GitHub SHA tarballs.
 
 ## Dependency shepherds

DEVELOPER.md

@@ -1,38 +1,38 @@
 # Developer documentation
 
 Envoy is built using the Bazel build system. Our CI on Azure Pipelines builds, tests, and runs coverage against
-all pull requests and the master branch.
+all pull requests and the main branch.
 
-To get started building Envoy locally, see the [Bazel quick start](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#quick-start-bazel-build-for-developers).
-To run tests, there are Bazel [targets](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#testing-envoy-with-bazel) for Google Test.
-To generate a coverage report, there is a [coverage build script](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#coverage-builds).
+To get started building Envoy locally, see the [Bazel quick start](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#quick-start-bazel-build-for-developers).
+To run tests, there are Bazel [targets](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#testing-envoy-with-bazel) for Google Test.
+To generate a coverage report, there is a [coverage build script](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#coverage-builds).
 
-If you plan to contribute to Envoy, you may find it useful to install the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/master/support/README.md), which helps automate parts of the development process, particularly those involving code review.
+If you plan to contribute to Envoy, you may find it useful to install the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/main/support/README.md), which helps automate parts of the development process, particularly those involving code review.
 
 Below is a list of additional documentation to aid the development process:
 
 - [General build and installation documentation](https://www.envoyproxy.io/docs/envoy/latest/start/start)
 
-- [Building and testing Envoy with Bazel](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md)
+- [Building and testing Envoy with Bazel](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md)
 
-- [Managing external dependencies with Bazel](https://github.com/envoyproxy/envoy/blob/master/bazel/EXTERNAL_DEPS.md)
+- [Managing external dependencies with Bazel](https://github.com/envoyproxy/envoy/blob/main/bazel/EXTERNAL_DEPS.md)
 
-- [Guide to Envoy Bazel rules (managing `BUILD` files)](https://github.com/envoyproxy/envoy/blob/master/bazel/DEVELOPER.md)
+- [Guide to Envoy Bazel rules (managing `BUILD` files)](https://github.com/envoyproxy/envoy/blob/main/bazel/DEVELOPER.md)
 
-- [Using Docker for building and testing](https://github.com/envoyproxy/envoy/tree/master/ci)
+- [Using Docker for building and testing](https://github.com/envoyproxy/envoy/tree/main/ci)
 
-- [Guide to contributing to Envoy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md)
+- [Guide to contributing to Envoy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md)
 
-- [Overview of Envoy's testing frameworks](https://github.com/envoyproxy/envoy/blob/master/test/README.md)
+- [Overview of Envoy's testing frameworks](https://github.com/envoyproxy/envoy/blob/main/test/README.md)
 
-- [Overview of how to write integration tests for new code](https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md)
+- [Overview of how to write integration tests for new code](https://github.com/envoyproxy/envoy/blob/main/test/integration/README.md)
 
 - [Envoy filter example project (how to consume and extend Envoy as a submodule)](https://github.com/envoyproxy/envoy-filter-example)
 
-- [Performance testing Envoy with `tcmalloc`/`pprof`](https://github.com/envoyproxy/envoy/blob/master/bazel/PPROF.md)
+- [Performance testing Envoy with `tcmalloc`/`pprof`](https://github.com/envoyproxy/envoy/blob/main/bazel/PPROF.md)
 
 And some documents on components of Envoy architecture:
 
-- [Envoy flow control](https://github.com/envoyproxy/envoy/blob/master/source/docs/flow_control.md)
+- [Envoy flow control](https://github.com/envoyproxy/envoy/blob/main/source/docs/flow_control.md)
 
-- [Envoy's subset load balancer](https://github.com/envoyproxy/envoy/blob/master/source/docs/subset_load_balancer.md)
+- [Envoy's subset load balancer](https://github.com/envoyproxy/envoy/blob/main/source/docs/subset_load_balancer.md)

EXTENSION_POLICY.md

@@ -15,7 +15,7 @@ The following procedure will be used when proposing new extensions for inclusion
   2. All extensions must be sponsored by an existing maintainer. Sponsorship means that the
   maintainer will shepherd the extension through design/code reviews. Maintainers can self-sponsor
   extensions if they are going to write them, shepherd them, and maintain them.
-  
+
      Sponsorship serves two purposes:
      * It ensures that the extension will ultimately meet the Envoy quality bar.
      * It makes sure that incentives are aligned and that extensions are not added to the repo without
@@ -24,7 +24,7 @@ The following procedure will be used when proposing new extensions for inclusion
      *If sponsorship cannot be found from an existing maintainer, an organization can consider
      [doing the work to become a maintainer](./GOVERNANCE.md#process-for-becoming-a-maintainer) in
      order to be able to self-sponsor extensions.*
-  
+
   3. Each extension must have two reviewers proposed for reviewing PRs to the extension. Neither of
   the reviewers must be a senior maintainer. Existing maintainers (including the sponsor) and other
   contributors can count towards this number. The initial reviewers will be codified in the
@@ -105,7 +105,7 @@ The `security_posture` is one of:
 * `unknown`: This is functionally equivalent to `requires_trusted_downstream_and_upstream`, but acts
   as a placeholder to allow us to identify extensions that need classifying.
 * `data_plane_agnostic`: Not relevant to data plane threats, e.g. stats sinks.
- 
+
 An assessment of a robust security posture for an extension is subject to the following guidelines:
 
 * Does the extension have fuzz coverage? If it's only receiving fuzzing
@@ -122,7 +122,7 @@ An assessment of a robust security posture for an extension is subject to the fo
 * Does the extension have active [CODEOWNERS](CODEOWNERS) who are willing to
   vouch for the robustness of the extension?
 * Is the extension absent a [low coverage
-  exception](https://github.com/envoyproxy/envoy/blob/master/test/per_file_coverage.sh#L5)?
+  exception](https://github.com/envoyproxy/envoy/blob/main/test/per_file_coverage.sh#L5)?
 
 The current stability and security posture of all extensions can be seen
 [here](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/threat_model#core-and-extensions).

GOVERNANCE.md

@@ -38,7 +38,7 @@
   The areas of specialization listed in [OWNERS.md](OWNERS.md) can be used to help with routing
   an issue/question to the right person.
 * Triage build issues - file issues for known flaky builds or bugs, and either fix or find someone
-  to fix any master build breakages.
+  to fix any main build breakages.
 * During GitHub issue triage, apply all applicable [labels](https://github.com/envoyproxy/envoy/labels)
   to each new issue. Labels are extremely useful for future issue follow up. Which labels to apply
   is somewhat subjective so just use your best judgment. A few of the most important labels that are
@@ -77,7 +77,7 @@ or you can subscribe to the iCal feed [here](webcal://kubernetes.app.opsgenie.co
   "is:open is:issue milestone:[current milestone]" and either hold off until
   they are fixed or bump them to the next milestone.
 * Begin marshalling the ongoing PR flow in this repo. Ask maintainers to hold off merging any
-  particularly risky PRs until after the release is tagged. This is because we aim for master to be
+  particularly risky PRs until after the release is tagged. This is because we aim for main to be
   at release candidate quality at all times.
 * Do a final check of the [release notes](docs/root/version_history/current.rst):
   * Make any needed corrections (grammar, punctuation, formatting, etc.).
@@ -91,7 +91,7 @@ or you can subscribe to the iCal feed [here](webcal://kubernetes.app.opsgenie.co
     release, please also make sure there's a stable maintainer signed up for next quarter,
     and the deadline for the next release is documented in the release schedule.
   * Get a review and merge.
-* Wait for tests to pass on [master](https://dev.azure.com/cncf/envoy/_build).
+* Wait for tests to pass on [main](https://dev.azure.com/cncf/envoy/_build).
 * Create a [tagged release](https://github.com/envoyproxy/envoy/releases). The release should
   start with "v" and be followed by the version number. E.g., "v1.6.0". **This must match the
   [VERSION](VERSION).**
@@ -106,7 +106,7 @@ or you can subscribe to the iCal feed [here](webcal://kubernetes.app.opsgenie.co
 * Make sure we tweet the new release: either have Matt do it or email [email protected] and ask them to do an Envoy account
   post.
 * Do a new PR to setup the next version
-  * Update [VERSION](VERSION) to the next development release. E.g., "1.7.0-dev". 
+  * Update [VERSION](VERSION) to the next development release. E.g., "1.7.0-dev".
   * `git mv docs/root/version_history/current.rst docs/root/version_history/v1.6.0.rst`, filling in the previous
     release version number in the filename and delete empty sections (like Incompatible Behavior Changes, Minor Bahavior Changes, etc).
     Add an entry for the new file in the `toctree` in

PULL_REQUEST_TEMPLATE.md

@@ -10,7 +10,7 @@ Thank you in advance for helping to keep Envoy secure.
 
 -->
 For an explanation of how to fill out the fields, please see the relevant section
-in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/master/PULL_REQUESTS.md)
+in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md)
 
 Commit Message:
 Additional Description:

README.md

@@ -65,7 +65,7 @@ have prior experience. To get started:
 * [Beginner issues](https://github.com/envoyproxy/envoy/issues?q=is%3Aopen+is%3Aissue+label%3Abeginner)
 * [Build/test quick start using docker](ci#building-and-running-tests-as-a-developer)
 * [Developer guide](DEVELOPER.md)
-* Consider installing the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/master/support/README.md), which helps automate parts of the development process, particularly those involving code review.
+* Consider installing the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/main/support/README.md), which helps automate parts of the development process, particularly those involving code review.
 * Please make sure that you let us know if you are working on an issue so we don't duplicate work!
 
 ## Community Meeting