From ce30dcf16ba096d95305237e84a16b769a2af909 Mon Sep 17 00:00:00 2001 From: Matt Klein Date: Fri, 15 Jan 2021 15:27:06 -0800 Subject: [PATCH] master -> main Various fixes Signed-off-by: Matt Klein --- .azure-pipelines/cve_scan.yml | 2 +- .azure-pipelines/pipelines.yml | 2 +- .bazelrc | 2 +- .../non--crash-security--bug.md | 4 +-- .github/workflows/get_build_targets.sh | 4 +-- CONTRIBUTING.md | 14 ++++---- DEPENDENCY_POLICY.md | 4 +-- DEVELOPER.md | 30 ++++++++--------- EXTENSION_POLICY.md | 8 ++--- GOVERNANCE.md | 8 ++--- PULL_REQUEST_TEMPLATE.md | 2 +- README.md | 2 +- RELEASES.md | 12 +++---- SECURITY.md | 16 +++++----- api/API_VERSIONING.md | 4 +-- api/CONTRIBUTING.md | 2 +- api/README.md | 4 +-- api/envoy/api/v2/core/protocol.proto | 2 +- api/envoy/config/core/v3/protocol.proto | 2 +- api/envoy/config/core/v4alpha/protocol.proto | 2 +- bazel/EXTERNAL_DEPS.md | 4 +-- bazel/PPROF.md | 6 ++-- bazel/README.md | 24 +++++++------- ci/README.md | 16 +++++----- ci/api_mirror.sh | 4 +-- ci/docker_ci.sh | 14 ++++---- ci/filter_example_mirror.sh | 4 +-- ci/go_mirror.sh | 2 +- ci/repokitteh/modules/newcontributor.star | 2 +- ci/upload_gcs_artifact.sh | 2 +- docs/README.md | 4 +-- docs/publish.sh | 4 +-- docs/root/version_history/v1.11.0.rst | 2 +- docs/root/version_history/v1.14.0.rst | 2 +- docs/root/version_history/v1.4.0.rst | 2 +- docs/root/version_history/v1.8.0.rst | 16 +++++----- docs/root/version_history/v1.9.0.rst | 10 +++--- docs/root/version_history/version_history.rst | 2 +- .../grpc-bridge/docker-compose-protos.yaml | 2 +- .../envoy/api/v2/core/protocol.proto | 2 +- .../envoy/config/core/v3/protocol.proto | 2 +- .../envoy/config/core/v4alpha/protocol.proto | 2 +- include/envoy/http/filter.h | 2 +- security/email-templates.md | 6 ++-- security/postmortems/cve-2019-15225.md | 2 +- security/postmortems/cve-2019-9900.md | 2 +- source/common/http/utility.cc | 2 +- source/common/stats/symbol_table_impl.cc | 4 +-- source/common/stats/thread_local_store.h | 2 +- source/common/stats/utility.h | 10 +++--- source/docs/network_filter_fuzzing.md | 32 +++++++++---------- source/docs/repokitteh.md | 4 +-- source/docs/stats.md | 20 ++++++------ test/README.md | 8 ++--- test/common/upstream/health_check_fuzz.cc | 2 +- .../filters/network/common/fuzz/README.md | 4 +-- test/integration/stats_integration_test.cc | 4 +-- tools/api/generate_go_protobuf.py | 2 +- tools/git/last_github_commit.sh | 4 +-- tools/proto_format/proto_sync.py | 2 +- 60 files changed, 183 insertions(+), 183 deletions(-) diff --git a/.azure-pipelines/cve_scan.yml b/.azure-pipelines/cve_scan.yml index 9cfe24497984..322adae2bb71 100644 --- a/.azure-pipelines/cve_scan.yml +++ b/.azure-pipelines/cve_scan.yml @@ -9,7 +9,7 @@ schedules: displayName: Hourly CVE scan branches: include: - - master + - main always: true pool: diff --git a/.azure-pipelines/pipelines.yml b/.azure-pipelines/pipelines.yml index 14cbb044ca5d..79e34999caa4 100644 --- a/.azure-pipelines/pipelines.yml +++ b/.azure-pipelines/pipelines.yml @@ -1,7 +1,7 @@ trigger: branches: include: - - "master" + - "main" - "release/v*" tags: include: diff --git a/.bazelrc b/.bazelrc index d43694e4ccf9..d399f2a5533f 100644 --- a/.bazelrc +++ b/.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 diff --git a/.github/ISSUE_TEMPLATE/non--crash-security--bug.md b/.github/ISSUE_TEMPLATE/non--crash-security--bug.md index 15c784680ecf..5b80df378a02 100644 --- a/.github/ISSUE_TEMPLATE/non--crash-security--bug.md +++ b/.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). diff --git a/.github/workflows/get_build_targets.sh b/.github/workflows/get_build_targets.sh index 25f67b74af50..874af4aefcc1 100755 --- a/.github/workflows/get_build_targets.sh +++ b/.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)) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 37d167e75032..0ed18c630a3b 100644 --- a/CONTRIBUTING.md +++ b/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 diff --git a/DEPENDENCY_POLICY.md b/DEPENDENCY_POLICY.md index 588dad437ad2..abefac1fe550 100644 --- a/DEPENDENCY_POLICY.md +++ b/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 diff --git a/DEVELOPER.md b/DEVELOPER.md index 6786925fa7e8..7a4ec69f54c6 100644 --- a/DEVELOPER.md +++ b/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) diff --git a/EXTENSION_POLICY.md b/EXTENSION_POLICY.md index 2f216813a6ff..39d41f14f875 100644 --- a/EXTENSION_POLICY.md +++ b/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). diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 1cb5157443ea..593a1c02e25a 100644 --- a/GOVERNANCE.md +++ b/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 social@cncf.io 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 diff --git a/PULL_REQUEST_TEMPLATE.md b/PULL_REQUEST_TEMPLATE.md index 366209eed929..962282df9920 100644 --- a/PULL_REQUEST_TEMPLATE.md +++ b/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: diff --git a/README.md b/README.md index 03c0aa0432d6..6d1108c05cb3 100644 --- a/README.md +++ b/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 diff --git a/RELEASES.md b/RELEASES.md index 085c58a2ce52..a630f49633e7 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -2,7 +2,7 @@ ## Active development -Active development is happening on the `master` branch, and a new version is released from it +Active development is happening on the `main` branch, and a new version is released from it at the end of each quarter. ## Stable releases @@ -10,23 +10,23 @@ at the end of each quarter. Stable releases of Envoy include: * Extended maintenance window (any version released in the last 12 months). -* Security fixes backported from the `master` branch (including those deemed not worthy +* Security fixes backported from the `main` branch (including those deemed not worthy of creating a CVE). -* Stability fixes backported from the `master` branch (anything that can result in a crash, +* Stability fixes backported from the `main` branch (anything that can result in a crash, including crashes triggered by a trusted control plane). * Bugfixes, deemed worthwhile by the maintainers of stable releases. ### Hand-off Hand-off to the maintainers of stable releases happens after Envoy maintainers release a new -version from the `master` branch by creating a `vX.Y.0` tag and a corresponding `release/vX.Y` +version from the `main` branch by creating a `vX.Y.0` tag and a corresponding `release/vX.Y` branch, with merge permissions given to the release manager of stable releases, and CI configured to execute tests on it. ### Security releases Critical security fixes are owned by the Envoy security team, which provides fixes for the -`master` branch, and the latest release branch. Once those fixes are ready, the maintainers +`main` branch, and the latest release branch. Once those fixes are ready, the maintainers of stable releases backport them to the remaining supported stable releases. ### Backports @@ -37,7 +37,7 @@ by adding the `backport/review` or `backport/approved` label (this can be done u `/backport` command). Changes nominated by the change author and/or members of the Envoy community are evaluated for backporting on a case-by-case basis, and require approval from either the release manager of stable release, Envoy maintainers, or Envoy security team. Once approved, those fixes -are backported from the `master` branch to all supported stable branches by the maintainers of +are backported from the `main` branch to all supported stable branches by the maintainers of stable releases. New stable versions from non-critical security fixes are released on a regular schedule, initially aiming for the bi-weekly releases. diff --git a/SECURITY.md b/SECURITY.md index 34138877e6b3..53b4de82b780 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -63,31 +63,31 @@ score >= 4; see below). If the fix relies on another upstream project's disclosu will adjust the process as well. We will work with the upstream project to fit their timeline and best protect our users. -### Released versions and master branch +### Released versions and main branch If the vulnerability affects the last point release version, e.g. 1.10, then the full security release process described in this document will be activated. A security point release will be -created for 1.10, e.g. 1.10.1, together with a fix to master if necessary. Older point releases, +created for 1.10, e.g. 1.10.1, together with a fix to main if necessary. Older point releases, e.g. 1.9, are not supported by the Envoy project and will not have any security release created. -If a security vulnerability affects only these older versions but not master or the last supported +If a security vulnerability affects only these older versions but not main or the last supported point release, the Envoy security team will share this information with the private distributor list, following the standard embargo process, but not create a security release. After the embargo expires, the vulnerability will be described as a GitHub issue. A CVE will be filed if warranted by severity. -If a vulnerability does not affect any point release but only master, additional caveats apply: +If a vulnerability does not affect any point release but only main, additional caveats apply: * If the issue is detected and a fix is available within 7 days of the introduction of the vulnerability, or the issue is deemed a low severity vulnerability by the Envoy maintainer and - security teams, the fix will be publicly reviewed and landed on master. If the severity is at least + security teams, the fix will be publicly reviewed and landed on main. If the severity is at least medium or at maintainer discretion a courtesy e-mail will be sent to envoy-users@googlegroups.com, envoy-dev@googlegroups.com, envoy-security-announce@googlegroups.com and cncf-envoy-distributors-announce@lists.cncf.io. * If the vulnerability has been in existence for more than 7 days and is medium or higher, we will activate the security release process. -We advise distributors and operators working from the master branch to allow at least 5 days soak +We advise distributors and operators working from the main branch to allow at least 5 days soak time after cutting a binary release before distribution or rollout, to allow time for our fuzzers to detect issues during their execution on ClusterFuzz. A soak period of 7 days provides an even stronger guarantee, since we will invoke the security release process for medium or higher severity issues @@ -181,7 +181,7 @@ patches, understand exact mitigation steps, etc. should be reserved for remotely exploitable or privilege escalation issues. Otherwise, this process can be skipped. - The Fix Lead will email the patches to cncf-envoy-distributors-announce@lists.cncf.io so - distributors can prepare builds to be available to users on the day of the issue's announcement. Any + distributors can prepare builds to be available to users on the day of the issue's announcement. Any patches against main will be updated and resent weekly. Distributors should read about the [Private Distributors List](#private-distributors-list) to find out the requirements for being added to this list. @@ -193,7 +193,7 @@ patches, understand exact mitigation steps, etc. - The maintainers will create a new patch release branch from the latest patch release tag + the fix from the security branch. As a practical example if v1.5.3 is the latest patch release in Envoy.git a new branch will be created called v1.5.4 which includes only patches required to fix the issue. -- The Fix Lead will cherry-pick the patches onto the master branch and all relevant release branches. +- The Fix Lead will cherry-pick the patches onto the main branch and all relevant release branches. The Fix Team will LGTM and merge. Maintainers will merge these PRs as quickly as possible. Changes shouldn't be made to the commits even for a typo in the CHANGELOG as this will change the git sha of the commits leading to confusion and potentially conflicts as the fix is cherry-picked around diff --git a/api/API_VERSIONING.md b/api/API_VERSIONING.md index 1757b0f2efce..6952ca0954ef 100644 --- a/api/API_VERSIONING.md +++ b/api/API_VERSIONING.md @@ -105,7 +105,7 @@ Envoy will support at most three major versions of any API package at all times: for the next stable major version. This is only generated when the current stable major version requires a breaking change at the next cycle, e.g. a deprecation or field rename. This release candidate is mechanically generated via the - [protoxform](https://github.com/envoyproxy/envoy/tree/master/tools/protoxform) tool from the + [protoxform](https://github.com/envoyproxy/envoy/tree/main/tools/protoxform) tool from the current stable major version, making use of annotations such as `deprecated = true`. This is not a human editable artifact. @@ -161,7 +161,7 @@ methods, depending on whether the change is mechanical or manual. ## Mechanical breaking changes Field deprecations, renames, etc. are mechanical changes that are supported by the -[protoxform](https://github.com/envoyproxy/envoy/tree/master/tools/protoxform) tool. These are +[protoxform](https://github.com/envoyproxy/envoy/tree/main/tools/protoxform) tool. These are guided by [annotations](STYLE.md#api-annotations). ## Manual breaking changes diff --git a/api/CONTRIBUTING.md b/api/CONTRIBUTING.md index 01ba39b500b8..847cdf74dc55 100644 --- a/api/CONTRIBUTING.md +++ b/api/CONTRIBUTING.md @@ -9,7 +9,7 @@ changes. They may be as part of a larger implementation PR. Please follow the st process for validating build/test sanity of `api/` before submitting a PR. *Note: New .proto files should be added to -[BUILD](https://github.com/envoyproxy/envoy/blob/master/api/versioning/BUILD) in order to get the RSTs generated.* +[BUILD](https://github.com/envoyproxy/envoy/blob/main/api/versioning/BUILD) in order to get the RSTs generated.* ## Documentation changes diff --git a/api/README.md b/api/README.md index fa6f3bb1eeba..94fce1159e46 100644 --- a/api/README.md +++ b/api/README.md @@ -9,9 +9,9 @@ blog post for more information on the universal data plane concept. # Repository structure The API tree can be found at two locations: -* https://github.com/envoyproxy/envoy/tree/master/api - canonical read/write home for the APIs. +* https://github.com/envoyproxy/envoy/tree/main/api - canonical read/write home for the APIs. * https://github.com/envoyproxy/data-plane-api - read-only mirror of - https://github.com/envoyproxy/envoy/tree/master/api, providing the ability to consume the data + https://github.com/envoyproxy/envoy/tree/main/api, providing the ability to consume the data plane APIs without the Envoy implementation. # Further API reading diff --git a/api/envoy/api/v2/core/protocol.proto b/api/envoy/api/v2/core/protocol.proto index 9c47e388ee1a..ae1a86424cf0 100644 --- a/api/envoy/api/v2/core/protocol.proto +++ b/api/envoy/api/v2/core/protocol.proto @@ -201,7 +201,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/api/envoy/config/core/v3/protocol.proto b/api/envoy/config/core/v3/protocol.proto index c294370366df..80d971c1466b 100644 --- a/api/envoy/config/core/v3/protocol.proto +++ b/api/envoy/config/core/v3/protocol.proto @@ -266,7 +266,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/api/envoy/config/core/v4alpha/protocol.proto b/api/envoy/config/core/v4alpha/protocol.proto index e33d83442afc..60f0b3210805 100644 --- a/api/envoy/config/core/v4alpha/protocol.proto +++ b/api/envoy/config/core/v4alpha/protocol.proto @@ -273,7 +273,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/bazel/EXTERNAL_DEPS.md b/bazel/EXTERNAL_DEPS.md index 4f66ef80eac8..02ba28e30674 100644 --- a/bazel/EXTERNAL_DEPS.md +++ b/bazel/EXTERNAL_DEPS.md @@ -78,7 +78,7 @@ documentation for further references. # Updating an external dependency version 1. Update the corresponding entry in -[the repository locations file.](https://github.com/envoyproxy/envoy/blob/master/bazel/repository_locations.bzl) +[the repository locations file.](https://github.com/envoyproxy/envoy/blob/main/bazel/repository_locations.bzl) 2. `bazel test //test/...` # Overriding an external dependency temporarily @@ -88,7 +88,7 @@ specifying Bazel option [`--override_repository`](https://docs.bazel.build/versions/master/command-line-reference.html) to point to a local copy. The option can used multiple times to override multiple dependencies. The name of the dependency can be found in -[the repository locations file.](https://github.com/envoyproxy/envoy/blob/master/bazel/repository_locations.bzl) +[the repository locations file.](https://github.com/envoyproxy/envoy/blob/main/bazel/repository_locations.bzl) The path of the local copy has to be absolute path. For repositories built by `envoy_cmake_external()` in `bazel/foreign_cc/BUILD`, diff --git a/bazel/PPROF.md b/bazel/PPROF.md index 74987b1986b4..2565a807b5e4 100644 --- a/bazel/PPROF.md +++ b/bazel/PPROF.md @@ -29,7 +29,7 @@ specific place yourself. Static linking is already available (because of a `HeapProfilerDump()` call inside -[`Envoy::Profiler::Heap::stopProfiler())`](https://github.com/envoyproxy/envoy/blob/master/source/common/profiler/profiler.cc#L32-L39)). +[`Envoy::Profiler::Heap::stopProfiler())`](https://github.com/envoyproxy/envoy/blob/main/source/common/profiler/profiler.cc#L32-L39)). ### Compiling a statically-linked Envoy @@ -82,7 +82,7 @@ is controlled by `ProfilerStart()`/`ProfilerStop()`, and the [Gperftools Heap Profiler](https://gperftools.github.io/gperftools/heapprofile.html) is controlled by `HeapProfilerStart()`, `HeapProfilerStop()` and `HeapProfilerDump()`. -These functions are wrapped by Envoy objects defined in [`source/common/profiler/profiler.h`](https://github.com/envoyproxy/envoy/blob/master/source/common/profiler/profiler.h)). +These functions are wrapped by Envoy objects defined in [`source/common/profiler/profiler.h`](https://github.com/envoyproxy/envoy/blob/main/source/common/profiler/profiler.h)). To enable profiling programmatically: @@ -258,7 +258,7 @@ account other memory allocating functions. In case there is a need to measure how long a code path takes time to execute in Envoy you may resort to instrumenting the code with the -[performance annotations](https://github.com/envoyproxy/envoy/blob/master/source/common/common/perf_annotation.h). +[performance annotations](https://github.com/envoyproxy/envoy/blob/main/source/common/common/perf_annotation.h). There are two types of the annotations. The first one is used to measure operations limited by a common lexical scope. For example: diff --git a/bazel/README.md b/bazel/README.md index e4d4d4a9cf22..8f9203d693d6 100644 --- a/bazel/README.md +++ b/bazel/README.md @@ -40,13 +40,13 @@ independently sourced, the following steps should be followed: This section describes how to and what dependencies to install to get started building Envoy with Bazel. If you would rather use a pre-build Docker image with required tools installed, skip to [this section](#building-envoy-with-the-ci-docker-image). -As a developer convenience, a [WORKSPACE](https://github.com/envoyproxy/envoy/blob/master/WORKSPACE) and +As a developer convenience, a [WORKSPACE](https://github.com/envoyproxy/envoy/blob/main/WORKSPACE) and [rules for building a recent -version](https://github.com/envoyproxy/envoy/blob/master/bazel/repositories.bzl) of the various Envoy +version](https://github.com/envoyproxy/envoy/blob/main/bazel/repositories.bzl) of the various Envoy dependencies are provided. These are provided as is, they are only suitable for development and testing purposes. The specific versions of the Envoy dependencies used in this build may not be up-to-date with the latest security patches. See -[this doc](https://github.com/envoyproxy/envoy/blob/master/bazel/EXTERNAL_DEPS.md#updating-an-external-dependency-version) +[this doc](https://github.com/envoyproxy/envoy/blob/main/bazel/EXTERNAL_DEPS.md#updating-an-external-dependency-version) for how to update or override dependencies. 1. Install external dependencies. @@ -84,14 +84,14 @@ for how to update or override dependencies. ``` Note: Either `libc++` or `libstdc++-7-dev` (or higher) must be installed. - + #### Config Flag Choices - Different [config](https://docs.bazel.build/versions/master/guide.html#--config) flags specify the compiler libraries: - + Different [config](https://docs.bazel.build/versions/master/guide.html#--config) flags specify the compiler libraries: + - `--config=libc++` means using `clang` + `libc++` - `--config=clang` means using `clang` + `libstdc++` - no config flag means using `gcc` + `libstdc++` - + ### macOS On macOS, you'll need to install several dependencies. This can be accomplished via [Homebrew](https://brew.sh/): @@ -256,7 +256,7 @@ MSYS2 or Git bash), run: ./ci/run_envoy_docker.sh './ci/windows_ci_steps.sh' ``` -See also the [documentation](https://github.com/envoyproxy/envoy/tree/master/ci) for developer use of the +See also the [documentation](https://github.com/envoyproxy/envoy/tree/main/ci) for developer use of the CI Docker image. ## Building Envoy with Remote Execution @@ -348,7 +348,7 @@ bazel test //test/... An individual test target can be run with a more specific Bazel [label](https://bazel.build/versions/master/docs/build-ref.html#Labels), e.g. to build and run only the units tests in -[test/common/http/async_client_impl_test.cc](https://github.com/envoyproxy/envoy/blob/master/test/common/http/async_client_impl_test.cc): +[test/common/http/async_client_impl_test.cc](https://github.com/envoyproxy/envoy/blob/main/test/common/http/async_client_impl_test.cc): ``` bazel test //test/common/http:async_client_impl_test @@ -749,7 +749,7 @@ test/run_envoy_bazel_coverage.sh **Note** that it is important to ensure that the versions of `clang`, `llvm-cov` and `llvm-profdata` are consistent and that they match the most recent Clang/LLVM toolchain version in use by Envoy (see the [build container -toolchain](https://github.com/envoyproxy/envoy-build-tools/blob/master/build_container/build_container_ubuntu.sh) for reference). +toolchain](https://github.com/envoyproxy/envoy-build-tools/blob/main/build_container/build_container_ubuntu.sh) for reference). The summary results are printed to the standard output and the full coverage report is available in `generated/coverage/coverage.html`. @@ -765,8 +765,8 @@ need to navigate down and open "coverage.html" but then you can navigate per nor have seen some issues with seeing the artifacts tab. If you can't see it, log out of Circle, and then log back in and it should start working. -The latest coverage report for master is available -[here](https://storage.googleapis.com/envoy-postsubmit/master/coverage/index.html). The latest fuzz coverage report for master is available [here](https://storage.googleapis.com/envoy-postsubmit/master/fuzz_coverage/index.html). +The latest coverage report for main is available +[here](https://storage.googleapis.com/envoy-postsubmit/main/coverage/index.html). The latest fuzz coverage report for main is available [here](https://storage.googleapis.com/envoy-postsubmit/main/fuzz_coverage/index.html). It's also possible to specialize the coverage build to a specified test or test dir. This is useful when doing things like exploring the coverage of a fuzzer over its corpus. This can be done by diff --git a/ci/README.md b/ci/README.md index 028e31263b30..9cde25759f94 100644 --- a/ci/README.md +++ b/ci/README.md @@ -6,24 +6,24 @@ and an image based on Windows2019. ## Ubuntu Envoy image The Ubuntu based Envoy Docker image at [`envoyproxy/envoy-build:`](https://hub.docker.com/r/envoyproxy/envoy-build/) is used for CI checks, -where `` is specified in [`envoy_build_sha.sh`](https://github.com/envoyproxy/envoy/blob/master/ci/envoy_build_sha.sh). Developers -may work with the latest build image SHA in [envoy-build-tools](https://github.com/envoyproxy/envoy-build-tools/blob/master/toolchains/rbe_toolchains_config.bzl#L8) +where `` is specified in [`envoy_build_sha.sh`](https://github.com/envoyproxy/envoy/blob/main/ci/envoy_build_sha.sh). Developers +may work with the latest build image SHA in [envoy-build-tools](https://github.com/envoyproxy/envoy-build-tools/blob/main/toolchains/rbe_toolchains_config.bzl#L8) repo to provide a self-contained environment for building Envoy binaries and running tests that reflects the latest built Ubuntu Envoy image. Moreover, the Docker image at [`envoyproxy/envoy-dev:`](https://hub.docker.com/r/envoyproxy/envoy-dev/) is an image that has an Envoy binary at `/usr/local/bin/envoy`. -The `` corresponds to the master commit at which the binary was compiled. Lastly, `envoyproxy/envoy-dev:latest` contains an Envoy -binary built from the latest tip of master that passed tests. +The `` corresponds to the main commit at which the binary was compiled. Lastly, `envoyproxy/envoy-dev:latest` contains an Envoy +binary built from the latest tip of main that passed tests. ## Alpine Envoy image Minimal images based on Alpine Linux allow for quicker deployment of Envoy. The Alpine base image is only built with symbols stripped. To get the binary with symbols, use the corresponding Ubuntu based debug image. The image is pushed with two different tags: `` and `latest`. Parallel to the Ubuntu images above, `` corresponds to the -master commit at which the binary was compiled, and `latest` corresponds to a binary built from the latest tip of master that passed tests. +main commit at which the binary was compiled, and `latest` corresponds to a binary built from the latest tip of main that passed tests. ## Windows 2019 Envoy image The Windows 2019 based Envoy Docker image at [`envoyproxy/envoy-build-windows2019:`](https://hub.docker.com/r/envoyproxy/envoy-build-windows2019/) -is used for CI checks, where `` is specified in [`envoy_build_sha.sh`](https://github.com/envoyproxy/envoy/blob/master/ci/envoy_build_sha.sh). +is used for CI checks, where `` is specified in [`envoy_build_sha.sh`](https://github.com/envoyproxy/envoy/blob/main/ci/envoy_build_sha.sh). Developers may work with the most recent `envoyproxy/envoy-build-windows2019` image to provide a self-contained environment for building Envoy binaries and running tests that reflects the latest built Windows 2019 Envoy image. @@ -44,7 +44,7 @@ We use the Clang compiler for all Linux CI runs with tests. We have an additiona # C++ standard library As of November 2019 after [#8859](https://github.com/envoyproxy/envoy/pull/8859) the official released binary is -[linked against libc++ on Linux](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#linking-against-libc-on-linux). +[linked against libc++ on Linux](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#linking-against-libc-on-linux). To override the C++ standard library in your build, set environment variable `ENVOY_STDLIB` to `libstdc++` or `libc++` and run `./ci/do_ci.sh` as described below. @@ -98,7 +98,7 @@ For a debug version of the Envoy binary you can run: The build artifact can be found in `/tmp/envoy-docker-build/envoy/source/exe/envoy-debug` (or wherever `$ENVOY_DOCKER_BUILD_DIR` points). -To leverage a [bazel remote cache](https://github.com/envoyproxy/envoy/tree/master/bazel#advanced-caching-setup) add the http_remote_cache endpoint to +To leverage a [bazel remote cache](https://github.com/envoyproxy/envoy/tree/main/bazel#advanced-caching-setup) add the http_remote_cache endpoint to the BAZEL_BUILD_EXTRA_OPTIONS environment variable ```bash diff --git a/ci/api_mirror.sh b/ci/api_mirror.sh index 03e8ab85d80c..8a3022b72431 100755 --- a/ci/api_mirror.sh +++ b/ci/api_mirror.sh @@ -3,8 +3,8 @@ set -e CHECKOUT_DIR=../data-plane-api -MAIN_BRANCH="refs/heads/master" -API_MAIN_BRANCH="master" +MAIN_BRANCH="refs/heads/main" +API_MAIN_BRANCH="main" if [[ "${AZP_BRANCH}" == "${MAIN_BRANCH}" ]]; then echo "Cloning..." diff --git a/ci/docker_ci.sh b/ci/docker_ci.sh index 3bd584923bdf..ab1283745037 100755 --- a/ci/docker_ci.sh +++ b/ci/docker_ci.sh @@ -101,11 +101,11 @@ push_images() { docker push "${BUILD_TAG}" } -MASTER_BRANCH="refs/heads/master" +MAIN_BRANCH="refs/heads/main" RELEASE_BRANCH_REGEX="^refs/heads/release/v.*" RELEASE_TAG_REGEX="^refs/tags/v.*" -# For master builds and release branch builds use the dev repo. Otherwise we assume it's a tag and +# For main builds and release branch builds use the dev repo. Otherwise we assume it's a tag and # we push to the primary repo. if [[ "${AZP_BRANCH}" =~ ${RELEASE_TAG_REGEX} ]]; then IMAGE_POSTFIX="" @@ -146,11 +146,11 @@ ENVOY_DOCKER_TAR="${ENVOY_DOCKER_IMAGE_DIRECTORY}/envoy-docker-images.tar.xz" echo "Saving built images to ${ENVOY_DOCKER_TAR}." docker save "${IMAGES_TO_SAVE[@]}" | xz -T0 -2 >"${ENVOY_DOCKER_TAR}" -# Only push images for master builds, release branch builds, and tag builds. -if [[ "${AZP_BRANCH}" != "${MASTER_BRANCH}" ]] && +# Only push images for main builds, release branch builds, and tag builds. +if [[ "${AZP_BRANCH}" != "${MAIN_BRANCH}" ]] && ! [[ "${AZP_BRANCH}" =~ ${RELEASE_BRANCH_REGEX} ]] && ! [[ "${AZP_BRANCH}" =~ ${RELEASE_TAG_REGEX} ]]; then - echo 'Ignoring non-master branch or tag for docker push.' + echo 'Ignoring non-main branch or tag for docker push.' exit 0 fi @@ -159,8 +159,8 @@ docker login -u "$DOCKERHUB_USERNAME" -p "$DOCKERHUB_PASSWORD" for BUILD_TYPE in "${BUILD_TYPES[@]}"; do push_images "${BUILD_TYPE}" "${DOCKER_IMAGE_PREFIX}${BUILD_TYPE}${IMAGE_POSTFIX}:${IMAGE_NAME}" - # Only push latest on master builds. - if [[ "${AZP_BRANCH}" == "${MASTER_BRANCH}" ]]; then + # Only push latest on main builds. + if [[ "${AZP_BRANCH}" == "${MAIN_BRANCH}" ]]; then docker tag "${DOCKER_IMAGE_PREFIX}${BUILD_TYPE}${IMAGE_POSTFIX}:${IMAGE_NAME}" "${DOCKER_IMAGE_PREFIX}${BUILD_TYPE}${IMAGE_POSTFIX}:latest" push_images "${BUILD_TYPE}" "${DOCKER_IMAGE_PREFIX}${BUILD_TYPE}${IMAGE_POSTFIX}:latest" fi diff --git a/ci/filter_example_mirror.sh b/ci/filter_example_mirror.sh index 8602b1677e4b..a51122771403 100755 --- a/ci/filter_example_mirror.sh +++ b/ci/filter_example_mirror.sh @@ -4,8 +4,8 @@ set -e ENVOY_SRCDIR=$(cd "$(dirname "${BASH_SOURCE[0]}")/../" && pwd) CHECKOUT_DIR=../envoy-filter-example -MAIN_BRANCH="refs/heads/master" -FILTER_EXAMPLE_MAIN_BRANCH="master" +MAIN_BRANCH="refs/heads/main" +FILTER_EXAMPLE_MAIN_BRANCH="main" if [[ "${AZP_BRANCH}" == "${MAIN_BRANCH}" ]]; then echo "Cloning..." diff --git a/ci/go_mirror.sh b/ci/go_mirror.sh index 63f96d0d7969..96743eef6262 100755 --- a/ci/go_mirror.sh +++ b/ci/go_mirror.sh @@ -2,7 +2,7 @@ set -e -MAIN_BRANCH="refs/heads/master" +MAIN_BRANCH="refs/heads/main" # shellcheck source=ci/setup_cache.sh . "$(dirname "$0")"/setup_cache.sh diff --git a/ci/repokitteh/modules/newcontributor.star b/ci/repokitteh/modules/newcontributor.star index a192bd8613e7..6bc5fc7071b2 100644 --- a/ci/repokitteh/modules/newcontributor.star +++ b/ci/repokitteh/modules/newcontributor.star @@ -4,7 +4,7 @@ Hi @%s, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. -In the meantime, please take a look at the [contribution guidelines](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md) if you have not done so already. +In the meantime, please take a look at the [contribution guidelines](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md) if you have not done so already. """ diff --git a/ci/upload_gcs_artifact.sh b/ci/upload_gcs_artifact.sh index aea9dbc3f24f..4a4bba6e4603 100755 --- a/ci/upload_gcs_artifact.sh +++ b/ci/upload_gcs_artifact.sh @@ -19,7 +19,7 @@ if [ ! -d "${SOURCE_DIRECTORY}" ]; then fi if [[ "$BUILD_REASON" == "PullRequest" ]]; then - # non-master upload to the last commit sha (first 7 chars) in the developers branch + # non-main upload to the last commit sha (first 7 chars) in the developers branch UPLOAD_PATH="$(git log --pretty=%P -n 1 | cut -d' ' -f2 | head -c7)" else UPLOAD_PATH="${SYSTEM_PULLREQUEST_PULLREQUESTNUMBER:-${BUILD_SOURCEBRANCHNAME}}" diff --git a/docs/README.md b/docs/README.md index 5cd5444d670b..27feeffc1564 100644 --- a/docs/README.md +++ b/docs/README.md @@ -6,7 +6,7 @@ In both cases, the generated output can be found in `generated/docs`. ## Building in an existing Envoy development environment -If you have an [existing Envoy development environment](https://github.com/envoyproxy/envoy/tree/master/bazel#quick-start-bazel-build-for-developers), you should have the necessary dependencies and requirements and be able to build the documentation directly. +If you have an [existing Envoy development environment](https://github.com/envoyproxy/envoy/tree/main/bazel#quick-start-bazel-build-for-developers), you should have the necessary dependencies and requirements and be able to build the documentation directly. ```bash ./docs/build.sh @@ -45,7 +45,7 @@ To do this: 1. The docs are published to [docs/envoy/latest](https://github.com/envoyproxy/envoyproxy.github.io/tree/master/docs/envoy/latest) on every commit to master. This process is handled by Azure Pipelines with the - [`publish.sh`](https://github.com/envoyproxy/envoy/blob/master/docs/publish.sh) script. + [`publish.sh`](https://github.com/envoyproxy/envoy/blob/main/docs/publish.sh) script. 2. The docs are published to [docs/envoy](https://github.com/envoyproxy/envoyproxy.github.io/tree/master/docs/envoy) in a directory named after every tagged commit in this repo. Thus, on every tagged release there diff --git a/docs/publish.sh b/docs/publish.sh index 11b75f1b77c9..1c65cdecae50 100755 --- a/docs/publish.sh +++ b/docs/publish.sh @@ -13,7 +13,7 @@ DOCS_DIR=generated/docs CHECKOUT_DIR=envoy-docs BUILD_SHA=$(git rev-parse HEAD) -MAIN_BRANCH="refs/heads/master" +MAIN_BRANCH="refs/heads/main" RELEASE_TAG_REGEX="^refs/tags/v.*" if [[ "${AZP_BRANCH}" =~ ${RELEASE_TAG_REGEX} ]]; then @@ -25,7 +25,7 @@ else exit 0 fi -DOCS_MAIN_BRANCH="master" +DOCS_MAIN_BRANCH="main" echo 'cloning' git clone git@github.com:envoyproxy/envoyproxy.github.io "${CHECKOUT_DIR}" -b "${DOCS_MAIN_BRANCH}" --depth 1 diff --git a/docs/root/version_history/v1.11.0.rst b/docs/root/version_history/v1.11.0.rst index 1bc4051b7da4..10b48736b2db 100644 --- a/docs/root/version_history/v1.11.0.rst +++ b/docs/root/version_history/v1.11.0.rst @@ -80,7 +80,7 @@ Changes * runtime: :ref:`Runtime Discovery Service (RTDS) ` support added to layered runtime configuration. * sandbox: added :ref:`CSRF sandbox `. * server: ``--define manual_stamp=manual_stamp`` was added to allow server stamping outside of binary rules. - more info in the `bazel docs `_. + more info in the `bazel docs `_. * server: added :ref:`server state ` statistic. * server: added :ref:`initialization_time_ms` statistic. * subset: added :ref:`list_as_any` option to diff --git a/docs/root/version_history/v1.14.0.rst b/docs/root/version_history/v1.14.0.rst index 2db9566c6788..649a34d1cce3 100644 --- a/docs/root/version_history/v1.14.0.rst +++ b/docs/root/version_history/v1.14.0.rst @@ -187,6 +187,6 @@ Deprecated and the previous default can be enabled until the end of the deprecation period by enabling runtime feature `envoy.deprecated_features.grpc_stats_filter_enable_stats_for_all_methods_by_default`. * The :ref:`source_ip ` field in - `RBAC `_ has been deprecated + `RBAC `_ has been deprecated in favor of :ref:`direct_remote_ip ` and :ref:`remote_ip `. diff --git a/docs/root/version_history/v1.4.0.rst b/docs/root/version_history/v1.4.0.rst index f940deb1b5a6..fb8105538627 100644 --- a/docs/root/version_history/v1.4.0.rst +++ b/docs/root/version_history/v1.4.0.rst @@ -56,7 +56,7 @@ Deprecated * The following log macros have been deprecated: `log_trace`, `log_debug`, `conn_log`, `conn_log_info`, `conn_log_debug`, `conn_log_trace`, `stream_log`, `stream_log_info`, `stream_log_debug`, `stream_log_trace`. For replacements, please see - `logger.h `_. + `logger.h `_. * The connectionId() and ssl() callbacks of StreamFilterCallbacks have been deprecated and replaced with a more general connection() callback, which, when not returning a nullptr, can be used to get the connection id and SSL connection from the returned Connection object pointer. diff --git a/docs/root/version_history/v1.8.0.rst b/docs/root/version_history/v1.8.0.rst index 5f05f5d7d8eb..e99c0e2c459c 100644 --- a/docs/root/version_history/v1.8.0.rst +++ b/docs/root/version_history/v1.8.0.rst @@ -106,24 +106,24 @@ Deprecated * Use of the legacy `ratelimit.proto `_ is deprecated, in favor of the proto defined in - `date-plane-api `_ + `date-plane-api `_ Prior to 1.8.0, Envoy can use either proto to send client requests to a ratelimit server with the use of the - `use_data_plane_proto` boolean flag in the `ratelimit configuration `_. + `use_data_plane_proto` boolean flag in the `ratelimit configuration `_. However, when using the deprecated client a warning is logged. * Use of the --v2-config-only flag. * Use of both `use_websocket` and `websocket_config` in - `route.proto `_ + `route.proto `_ is deprecated. Please use the new `upgrade_configs` in the - `HttpConnectionManager `_ + `HttpConnectionManager `_ instead. -* Use of the integer `percent` field in `FaultDelay `_ - and in `FaultAbort `_ is deprecated in favor +* Use of the integer `percent` field in `FaultDelay `_ + and in `FaultAbort `_ is deprecated in favor of the new `FractionalPercent` based `percentage` field. * Setting hosts via `hosts` field in `Cluster` is deprecated. Use `load_assignment` instead. * Use of `response_headers_to_*` and `request_headers_to_add` are deprecated at the `RouteAction` level. Please use the configuration options at the `Route` level. * Use of `runtime` in `RouteMatch`, found in - `route.proto `_. + `route.proto `_. Set the `runtime_fraction` field instead. -* Use of the string `user` field in `Authenticated` in `rbac.proto `_ +* Use of the string `user` field in `Authenticated` in `rbac.proto `_ is deprecated in favor of the new `StringMatcher` based `principal_name` field. diff --git a/docs/root/version_history/v1.9.0.rst b/docs/root/version_history/v1.9.0.rst index 54cd1e478336..12614ca1497b 100644 --- a/docs/root/version_history/v1.9.0.rst +++ b/docs/root/version_history/v1.9.0.rst @@ -102,12 +102,12 @@ Changes Deprecated ---------- -* Order of execution of the network write filter chain has been reversed. Prior to this release cycle it was incorrect, see `#4599 `_. In the 1.9.0 release cycle we introduced `bugfix_reverse_write_filter_order` in `lds.proto `_ to temporarily support both old and new behaviors. Note this boolean field is deprecated. -* Order of execution of the HTTP encoder filter chain has been reversed. Prior to this release cycle it was incorrect, see `#4599 `_. In the 1.9.0 release cycle we introduced `bugfix_reverse_encode_order` in `http_connection_manager.proto `_ to temporarily support both old and new behaviors. Note this boolean field is deprecated. +* Order of execution of the network write filter chain has been reversed. Prior to this release cycle it was incorrect, see `#4599 `_. In the 1.9.0 release cycle we introduced `bugfix_reverse_write_filter_order` in `lds.proto `_ to temporarily support both old and new behaviors. Note this boolean field is deprecated. +* Order of execution of the HTTP encoder filter chain has been reversed. Prior to this release cycle it was incorrect, see `#4599 `_. In the 1.9.0 release cycle we introduced `bugfix_reverse_encode_order` in `http_connection_manager.proto `_ to temporarily support both old and new behaviors. Note this boolean field is deprecated. * Use of the v1 REST_LEGACY ApiConfigSource is deprecated. * Use of std::hash in the ring hash load balancer is deprecated. -* Use of `rate_limit_service` configuration in the `bootstrap configuration `_ is deprecated. +* Use of `rate_limit_service` configuration in the `bootstrap configuration `_ is deprecated. * Use of `runtime_key` in `RequestMirrorPolicy`, found in - `route.proto `_ + `route.proto `_ is deprecated. Set the `runtime_fraction` field instead. -* Use of buffer filter `max_request_time` is deprecated in favor of the request timeout found in `HttpConnectionManager `_ +* Use of buffer filter `max_request_time` is deprecated in favor of the request timeout found in `HttpConnectionManager `_ diff --git a/docs/root/version_history/version_history.rst b/docs/root/version_history/version_history.rst index 32c63cf7a0dc..4c5410a6f9cb 100644 --- a/docs/root/version_history/version_history.rst +++ b/docs/root/version_history/version_history.rst @@ -60,7 +60,7 @@ Deprecation Policy ^^^^^^^^^^^^^^^^^^ As of release 1.3.0, Envoy will follow a -`Breaking Change Policy `_. +`Breaking Change Policy `_. Features in the deprecated list for each version have been DEPRECATED and will be removed in the specified release cycle. A logged warning diff --git a/examples/grpc-bridge/docker-compose-protos.yaml b/examples/grpc-bridge/docker-compose-protos.yaml index 42da7d7407c7..543fe4bf5aca 100644 --- a/examples/grpc-bridge/docker-compose-protos.yaml +++ b/examples/grpc-bridge/docker-compose-protos.yaml @@ -1,7 +1,7 @@ version: "3.7" # This is the conversion from a script to a dockerized version of the script -# https://github.com/envoyproxy/envoy/blob/master/examples/grpc-bridge/service/script/gen +# https://github.com/envoyproxy/envoy/blob/main/examples/grpc-bridge/service/script/gen services: # $ docker run -ti -v $(pwd):/protos -v $(pwd)/stubs:/stubs grpc/go protoc --go_out=plugins=grpc:/stubs -I/protos /protos/kv.proto diff --git a/generated_api_shadow/envoy/api/v2/core/protocol.proto b/generated_api_shadow/envoy/api/v2/core/protocol.proto index 9c47e388ee1a..ae1a86424cf0 100644 --- a/generated_api_shadow/envoy/api/v2/core/protocol.proto +++ b/generated_api_shadow/envoy/api/v2/core/protocol.proto @@ -201,7 +201,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/generated_api_shadow/envoy/config/core/v3/protocol.proto b/generated_api_shadow/envoy/config/core/v3/protocol.proto index c294370366df..80d971c1466b 100644 --- a/generated_api_shadow/envoy/config/core/v3/protocol.proto +++ b/generated_api_shadow/envoy/config/core/v3/protocol.proto @@ -266,7 +266,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/generated_api_shadow/envoy/config/core/v4alpha/protocol.proto b/generated_api_shadow/envoy/config/core/v4alpha/protocol.proto index 2063d6d6793e..c9fc21d4cfa4 100644 --- a/generated_api_shadow/envoy/config/core/v4alpha/protocol.proto +++ b/generated_api_shadow/envoy/config/core/v4alpha/protocol.proto @@ -269,7 +269,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/include/envoy/http/filter.h b/include/envoy/http/filter.h index cd3c1744140f..605177c2c8df 100644 --- a/include/envoy/http/filter.h +++ b/include/envoy/http/filter.h @@ -49,7 +49,7 @@ enum class FilterHeadersStatus { // injectDecodedDataToFilterChain()/injectEncodedDataToFilterChain(), possibly multiple times // if the body needs to be divided into several chunks. The filter may need to handle // watermark events when injecting a body, see: - // https://github.com/envoyproxy/envoy/blob/master/source/docs/flow_control.md. + // https://github.com/envoyproxy/envoy/blob/main/source/docs/flow_control.md. // // The last call to inject data MUST have end_stream set to true to conclude the stream. // If the filter cannot provide a body the stream should be reset. diff --git a/security/email-templates.md b/security/email-templates.md index ec76e6d82748..3e6c17897866 100644 --- a/security/email-templates.md +++ b/security/email-templates.md @@ -36,14 +36,14 @@ Hello Envoy Distributors, The Envoy security team would like to provide advanced notice to the Envoy Private Distributors List of some details on the pending Envoy $VERSION security release, following the process described at -https://github.com/envoyproxy/envoy/blob/master/SECURITY.md. +https://github.com/envoyproxy/envoy/blob/main/SECURITY.md. This release will be made available on the $ORDINALDAY of $MONTH $YEAR at $PDTHOUR PDT ($GMTHOUR GMT). This release will fix $NUMDEFECTS security defect(s). The highest rated security defect is considered $SEVERITY severity. Below we provide details of these vulnerabilities under our embargo policy -(https://github.com/envoyproxy/envoy/blob/master/SECURITY.md#embargo-policy). +(https://github.com/envoyproxy/envoy/blob/main/SECURITY.md#embargo-policy). This information should be treated as confidential until public release by the Envoy maintainers on the Envoy GitHub. @@ -86,7 +86,7 @@ As a reminder, these patches are under embargo until $ORDINALDAY of $MONTH $YEAR at $PDTHOUR PDT ($GMTHOUR GMT). The information below should be treated as confidential and shared only on a need-to-know basis. The rules outline in our embargo policy -(https://github.com/envoyproxy/envoy/blob/master/SECURITY.md#embargo-policy) +(https://github.com/envoyproxy/envoy/blob/main/SECURITY.md#embargo-policy) still apply, and it is extremely important that any communication related to these CVEs are not forwarded further. diff --git a/security/postmortems/cve-2019-15225.md b/security/postmortems/cve-2019-15225.md index 1fbd02727822..7b3635ca70c1 100644 --- a/security/postmortems/cve-2019-15225.md +++ b/security/postmortems/cve-2019-15225.md @@ -130,7 +130,7 @@ amplify the effect of the O(n^2) process enough to produce a timeout. * The fixes for CVE-2019-15226 were straightforward and localized. * The security release occurred on time and followed the guidelines established in - https://github.com/envoyproxy/envoy/blob/master/SECURITY.md + https://github.com/envoyproxy/envoy/blob/main/SECURITY.md ### What went wrong diff --git a/security/postmortems/cve-2019-9900.md b/security/postmortems/cve-2019-9900.md index d6b6d38af579..2766d1a647ba 100644 --- a/security/postmortems/cve-2019-9900.md +++ b/security/postmortems/cve-2019-9900.md @@ -303,7 +303,7 @@ All times US/Pacific number of users. 2019-04-04: -* 15:41 The Envoy master branch was frozen to prepare for the security release. PRs were rebased +* 15:41 The Envoy main branch was frozen to prepare for the security release. PRs were rebased against master and prepared for the release push. * 18:33 Envoy security team was contacted by a distributor who had noticed public visibility of binary images with the fix patch by other vendors. After discussion, we agreed on a general diff --git a/source/common/http/utility.cc b/source/common/http/utility.cc index ff2cae86e262..86660479c683 100644 --- a/source/common/http/utility.cc +++ b/source/common/http/utility.cc @@ -554,7 +554,7 @@ void Utility::sendLocalReply(const bool& is_reset, const EncodeFunctions& encode // TODO(dio): Probably it is worth to consider caching the encoded message based on gRPC // status. // JsonFormatter adds a '\n' at the end. For header value, it should be removed. - // https://github.com/envoyproxy/envoy/blob/master/source/common/formatter/substitution_formatter.cc#L129 + // https://github.com/envoyproxy/envoy/blob/main/source/common/formatter/substitution_formatter.cc#L129 if (body_text[body_text.length() - 1] == '\n') { body_text = body_text.substr(0, body_text.length() - 1); } diff --git a/source/common/stats/symbol_table_impl.cc b/source/common/stats/symbol_table_impl.cc index f7799a7fc55f..22529eadab7e 100644 --- a/source/common/stats/symbol_table_impl.cc +++ b/source/common/stats/symbol_table_impl.cc @@ -246,12 +246,12 @@ void SymbolTableImpl::incRefCount(const StatName& stat_name) { ASSERT(decode_search != decode_map_.end(), "Please see " - "https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#" + "https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#" "debugging-symbol-table-assertions"); auto encode_search = encode_map_.find(decode_search->second->toStringView()); ASSERT(encode_search != encode_map_.end(), "Please see " - "https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#" + "https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#" "debugging-symbol-table-assertions"); ++encode_search->second.ref_count_; diff --git a/source/common/stats/thread_local_store.h b/source/common/stats/thread_local_store.h index dd66d137b491..946a84ed874c 100644 --- a/source/common/stats/thread_local_store.h +++ b/source/common/stats/thread_local_store.h @@ -141,7 +141,7 @@ using ParentHistogramImplSharedPtr = RefcountPtr; /** * Store implementation with thread local caching. For design details see - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md */ class ThreadLocalStoreImpl : Logger::Loggable, public StoreRoot { public: diff --git a/source/common/stats/utility.h b/source/common/stats/utility.h index 7ca48a2a10ef..90c1aa54ff10 100644 --- a/source/common/stats/utility.h +++ b/source/common/stats/utility.h @@ -68,7 +68,7 @@ class Utility { * Creates a nested scope from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also scopeFromStatNames, which is slightly faster but does not allow @@ -97,7 +97,7 @@ class Utility { * Creates a counter from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also counterFromStatNames, which is slightly faster but does not allow @@ -130,7 +130,7 @@ class Utility { * Creates a gauge from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also gaugeFromStatNames, which is slightly faster but does not allow @@ -167,7 +167,7 @@ class Utility { * Creates a histogram from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also histogramFromStatNames, which is slightly faster but does not allow @@ -204,7 +204,7 @@ class Utility { * Creates a TextReadout from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also TextReadoutFromStatNames, which is slightly faster but does not allow diff --git a/source/docs/network_filter_fuzzing.md b/source/docs/network_filter_fuzzing.md index 1777c7776774..8e40210cac24 100644 --- a/source/docs/network_filter_fuzzing.md +++ b/source/docs/network_filter_fuzzing.md @@ -1,17 +1,17 @@ # Generic network-level filter fuzzers overview -Network filters need to be fuzzed. Filters come in two flavors, each with their own fuzzer. Read filters should be added into the [Generic ReadFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz_test.cc). Write Filters should added into the [Generic WriteFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz_test.cc). Some filters are both raed and write filters: They should be added into both fuzzers. +Network filters need to be fuzzed. Filters come in two flavors, each with their own fuzzer. Read filters should be added into the [Generic ReadFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz_test.cc). Write Filters should added into the [Generic WriteFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz_test.cc). Some filters are both raed and write filters: They should be added into both fuzzers. Before adding the new filter into the fuzzers, please make sure the filter is designed to accept untrusted inputs, or ready to be hardened to accept untrusted inputs. # Add a new ReadFilter into Generic Readfilter Fuzzer ## Step1. Make sure the filter can be linked into the fuzzer -There are two ways to link it into the fuzzer. -* [Recommended] In the file [extensions_build_config.bzl](https://github.com/envoyproxy/envoy/blob/master/source/extensions/extensions_build_config.bzl), the name of the filter should have a prefix `envoy.filters.network`. If it has such a prefix, the filter will be automatically linked into Generic ReadFilter Fuzzer. -* [Not recommended]If for some reasons the filter's name doesn't have such a prefix, the config of the filter must be added into the `deps` field of `network_readfilter_fuzz_test` module in the file [BUILD](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/BUILD). +There are two ways to link it into the fuzzer. +* [Recommended] In the file [extensions_build_config.bzl](https://github.com/envoyproxy/envoy/blob/main/source/extensions/extensions_build_config.bzl), the name of the filter should have a prefix `envoy.filters.network`. If it has such a prefix, the filter will be automatically linked into Generic ReadFilter Fuzzer. +* [Not recommended]If for some reasons the filter's name doesn't have such a prefix, the config of the filter must be added into the `deps` field of `network_readfilter_fuzz_test` module in the file [BUILD](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/BUILD). ### Step2. Add the filter name into supported_filter_names -In [uber_per_readfilter.cc](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/uber_per_readfilter.cc), add the filter name into the vector `supported_filter_names` in method `UberFilterFuzzer::filterNames()`. +In [uber_per_readfilter.cc](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/uber_per_readfilter.cc), add the filter name into the vector `supported_filter_names` in method `UberFilterFuzzer::filterNames()`. ``` const std::vector supported_filter_names = { ... @@ -22,7 +22,7 @@ NetworkFilterNames::get().ExtAuthorization, NetworkFilterNames::get().TheNewFilt # Add a new WriteFilter into Generic Writefilter Fuzzer ## Step 1. Make sure the filter can be linked into the fuzzer -For WriteFilter, the config of the filter must be added into the `deps` field of `network_writefilter_fuzz_test` module in the file [BUILD](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/BUILD). +For WriteFilter, the config of the filter must be added into the `deps` field of `network_writefilter_fuzz_test` module in the file [BUILD](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/BUILD). ``` envoy_cc_fuzz_test( name = "network_writefilter_fuzz_test", @@ -43,7 +43,7 @@ envoy_cc_fuzz_test( ) ``` ## Step 2. Add the filter name into supported_filter_names -In [uber_per_writefilter.cc](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/uber_per_writefilter.cc), add the filter name into the vector `supported_filter_names` in method `UberWriteFilterFuzzer::filterNames()`. +In [uber_per_writefilter.cc](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/uber_per_writefilter.cc), add the filter name into the vector `supported_filter_names` in method `UberWriteFilterFuzzer::filterNames()`. ``` const std::vector supported_filter_names = { ... @@ -54,8 +54,8 @@ const std::vector supported_filter_names = { # Add test cases into corpus Good test cases can provide good examples for fuzzers to find more paths in the code, increase the coverage and help find bugs more efficiently. -Each test case is a file under the folder [network_readfilter_corpus](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_readfilter_corpus) or [network_writefilter_corpus](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_writefilter_corpus). It consists of two parts: `config` and `actions`. -`config` is the protobuf to instantiate a filter, and `actions` are sequences of actions to take in order to test the filter. +Each test case is a file under the folder [network_readfilter_corpus](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_readfilter_corpus) or [network_writefilter_corpus](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_writefilter_corpus). It consists of two parts: `config` and `actions`. +`config` is the protobuf to instantiate a filter, and `actions` are sequences of actions to take in order to test the filter. An example for testing MongoProxy filter: ``` config { @@ -80,14 +80,14 @@ actions { } } ``` -* `config.name` is the name of the filter. -* `config.typed_config.type_url` is the type url of the filter config API. +* `config.name` is the name of the filter. +* `config.typed_config.type_url` is the type url of the filter config API. * `config.typed_config.value` is the serialized string of the config protobuf, and in C++ we can call`config.SerializeAsString()` to obtain this. This string may contain special characters. Recommend using octal or hexadecimal sequence for the string. * `actions.on_data.data` (or `actions.on_write.data`) is the buffer parameter `data`(in string format) for testing ReadFilter's method onData() (or for testing WriteFilter's method onWrite()). This string may contain special characters. Recommend using octal or hexadecimal sequence for the string. * `actions.on_data.end_stream` (or `actions.on_write.end_stream`) is the bool parameter `end_stream` for testing ReadFilter's method onData() (or for testing WriteFilter's method onWrite()). * `actions.on_new_connection` is an action to call `onNewConnection` method of a ReadFilter. * `actions.advance_time.milliseconds` is the duration in milliseconds for the simulatedSystemTime to advance by. -For more details, see the APIs for [ReadFilter Fuzz Testcase](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz.proto) and [WriteFilter Fuzz Testcase](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz.proto). +For more details, see the APIs for [ReadFilter Fuzz Testcase](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz.proto) and [WriteFilter Fuzz Testcase](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz.proto). ## Convert a unit test case to a fuzz test case manually This section explains an approach to generate a corpus from unit tests. It is an optional step for users who want to generate the highest possible coverage. @@ -105,12 +105,12 @@ static std::string toOct(const std::string& source, const std::string& info) { } ``` In the unit test code, we temporarily add a function(finally we will remove it) like the above one. -Then we can fill in `config.typed_config.value` with the value returned or printed by -```toOct(config.SerializeAsString(), "config serialized string: ")``` +Then we can fill in `config.typed_config.value` with the value returned or printed by +```toOct(config.SerializeAsString(), "config serialized string: ")``` where `config` is the config protobuf in a unit test case. -We can also fill in `actions.on_data.data` or `actions.on_write.data` with the value returned or printed by -```toOct(buffer.toString(), "buffer:")``` +We can also fill in `actions.on_data.data` or `actions.on_write.data` with the value returned or printed by +```toOct(buffer.toString(), "buffer:")``` where `buffer` is the buffer to pass to `onData()` or `onWrite()` in a unit test case. Please note that the two fuzzers use the "real input" for fuzzers. If you are using a mock decoder and pass an empty buffer to onData(), that test case won't help cover much code in the fuzzers(but the config protobuf is still helpful). diff --git a/source/docs/repokitteh.md b/source/docs/repokitteh.md index 0d07ba9ddc26..f8a442798afe 100644 --- a/source/docs/repokitteh.md +++ b/source/docs/repokitteh.md @@ -8,7 +8,7 @@ The application is installed on specific GitHub repositories and interacts with these by receiving webhooks and making GitHub API calls. A root `repokitteh.star` script tells the application what to do based on the webhook received. ## Integration with Envoy -The file [repokitteh.star](https://github.com/envoyproxy/envoy/blob/master/repokitteh.star), which resides in the root of the Envoy repository tells RepoKitteh what functionality to use. The file is written in the [Starlark language](https://github.com/bazelbuild/starlark/), which is a Python dialect with well defined threading and hermeticity guarantees. +The file [repokitteh.star](https://github.com/envoyproxy/envoy/blob/main/repokitteh.star), which resides in the root of the Envoy repository tells RepoKitteh what functionality to use. The file is written in the [Starlark language](https://github.com/bazelbuild/starlark/), which is a Python dialect with well defined threading and hermeticity guarantees. For example, the statement ``` @@ -75,7 +75,7 @@ Sets the label `waiting:any` on a PR. When a new commit is pushed or any comment [Demo PR](https://github.com/envoyproxy/envoybot/pull/15) -### [Azure Pipelines Retest](https://github.com/envoyproxy/envoy/blob/master/ci/repokitteh/modules/azure_pipelines.star) +### [Azure Pipelines Retest](https://github.com/envoyproxy/envoy/blob/main/ci/repokitteh/modules/azure_pipelines.star) Restart failed Azure pipelines. Example: diff --git a/source/docs/stats.md b/source/docs/stats.md index af0b0f7eca39..de9a92048f69 100644 --- a/source/docs/stats.md +++ b/source/docs/stats.md @@ -25,7 +25,7 @@ https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310 for details. This requires lock-free access to stats on the fast path -- when proxying requests. For stats, this is implemented in -[ThreadLocalStore](https://github.com/envoyproxy/envoy/blob/master/source/common/stats/thread_local_store.h), supporting the following features: +[ThreadLocalStore](https://github.com/envoyproxy/envoy/blob/main/source/common/stats/thread_local_store.h), supporting the following features: * Thread local per scope stat caching. * Overlapping scopes with proper reference counting (2 scopes with the same name will point to @@ -94,12 +94,12 @@ maintain data continuity as scopes are re-created during operation. Stat names are replicated in several places in various forms. * Held with the stat values, in `CounterImpl`, `GaugeImpl` and `TextReadoutImpl`, which are defined in - [allocator_impl.cc](https://github.com/envoyproxy/envoy/blob/master/source/common/stats/allocator_impl.cc) - * In [MetricImpl](https://github.com/envoyproxy/envoy/blob/master/source/common/stats/metric_impl.h) + [allocator_impl.cc](https://github.com/envoyproxy/envoy/blob/main/source/common/stats/allocator_impl.cc) + * In [MetricImpl](https://github.com/envoyproxy/envoy/blob/main/source/common/stats/metric_impl.h) in a transformed state, with tags extracted into vectors of name/value strings. * In static strings across the codebase where stats are referenced * In a [set of - regexes](https://github.com/envoyproxy/envoy/blob/master/source/common/config/well_known_names.cc) + regexes](https://github.com/envoyproxy/envoy/blob/main/source/common/config/well_known_names.cc) used to perform tag extraction. There are stat maps in `ThreadLocalStore` for capturing all stats in a scope, @@ -127,7 +127,7 @@ The transformation between flattened string and symbolized form is CPU-intensive at scale. It requires parsing, encoding, and lookups in a shared map, which must be mutex-protected. To avoid adding latency and CPU overhead while serving requests, the tokens can be symbolized and saved in context classes, such as -[Http::CodeStatsImpl](https://github.com/envoyproxy/envoy/blob/master/source/common/http/codes.h). +[Http::CodeStatsImpl](https://github.com/envoyproxy/envoy/blob/main/source/common/http/codes.h). Symbolization can occur on startup or when new hosts or clusters are configured dynamically. Users of stats that are allocated dynamically per cluster, host, etc, must explicitly store partial stat-names their class instances, which later @@ -184,7 +184,7 @@ showing the memory layout for a few scenarios of constructing and joining symbol There are several ways to create hot-path contention looking up stats by name, and there is no bulletproof way to prevent it from occurring. - * The [stats macros](https://github.com/envoyproxy/envoy/blob/master/include/envoy/stats/stats_macros.h) may be used in a data structure which is constructed in response to requests. In this + * The [stats macros](https://github.com/envoyproxy/envoy/blob/main/include/envoy/stats/stats_macros.h) may be used in a data structure which is constructed in response to requests. In this scenario, consider factoring out the symbolization phase using MAKE_STAT_NAMES_STRUCT in a factory or context during startup, and using MAKE_STATS_STRUCT in the hot-path and during control-plane updates, so that we do not need to take symbol-table locks. As an example, see @@ -210,7 +210,7 @@ SymbolTableImpl::Encoding | | Helper class for incrementally encoding strings in StatName | | Provides an API and a view into a StatName (dynamic or symbolized). Like absl::string_view, the backing store must be separately maintained. StatNameStorageBase | | Holds storage (an array of bytes) for a dynamic or symbolized StatName StatNameStorage | StatNameStorageBase | Holds storage for a symbolized StatName. Must be explicitly freed (not just destructed). -StatNameManagedStorage | StatNameStorage | Like StatNameStorage, but is 8 bytes larger, and can be destructed without free(). +StatNameManagedStorage | StatNameStorage | Like StatNameStorage, but is 8 bytes larger, and can be destructed without free(). StatNameDynamicStorage | StatNameStorageBase | Holds StatName storage for a dynamic (not symbolized) StatName. StatNamePool | | Holds backing store for any number of symbolized StatNames. StatNameDynamicPool | | Holds backing store for any number of dynamic StatNames. @@ -251,7 +251,7 @@ deployments with O(10k) clusters or hosts. To improve visibility for this memory growth, there are [memory-usage integration -tests](https://github.com/envoyproxy/envoy/blob/master/test/integration/stats_integration_test.cc). +tests](https://github.com/envoyproxy/envoy/blob/main/test/integration/stats_integration_test.cc). If a PR fails the tests in that file due to unexpected memory consumption, it gives the author and reviewer an opportunity to consider the cost/value of the @@ -275,8 +275,8 @@ If you are visiting this section because you saw a message like: ```bash [...][16][critical][assert] [source/common/stats/symbol_table_impl.cc:251] assert failure: -decode_search != decode_map_.end(). Details: Please see -https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#debugging-symbol-table-assertions +decode_search != decode_map_.end(). Details: Please see +https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#debugging-symbol-table-assertions ``` then you have come to the right place. diff --git a/test/README.md b/test/README.md index 2746efe98c8d..85f12625902f 100644 --- a/test/README.md +++ b/test/README.md @@ -10,7 +10,7 @@ various classes, macros, and matchers that Envoy uses from those frameworks. Envoy contains an integration testing framework, for testing downstream-Envoy-upstream communication. -[See the framework's README for more information.](https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md) +[See the framework's README for more information.](https://github.com/envoyproxy/envoy/blob/main/test/integration/README.md) ## Custom matchers @@ -93,7 +93,7 @@ EXPECT_THAT(response->headers(), IsSupersetOfHeaders(required_headers)); ## Controlling time in tests In Envoy production code, time and timers are managed via -[`Event::TimeSystem`](https://github.com/envoyproxy/envoy/blob/master/include/envoy/event/timer.h), +[`Event::TimeSystem`](https://github.com/envoyproxy/envoy/blob/main/include/envoy/event/timer.h), which provides a mechanism for querying the time and setting up time-based callbacks. Bypassing this abstraction in Envoy code is flagged as a format violation in CI. @@ -127,7 +127,7 @@ Envoy uses [Google Benchmark](https://github.com/google/benchmark/) for microbenchmarks. There are custom bazel rules, `envoy_cc_benchmark_binary` and `envoy_benchmark_test`, to execute them locally and in CI environments respectively. `envoy_benchmark_test` rules call the benchmark binary from a -[script](https://github.com/envoyproxy/envoy/blob/master/bazel/test_for_benchmark_wrapper.sh) +[script](https://github.com/envoyproxy/envoy/blob/main/bazel/test_for_benchmark_wrapper.sh) which runs the benchmark with a minimal number of iterations and skipping expensive benchmarks to quickly verify that the binary is able to run to completion. In order to collect meaningful bechmarks, `bazel run -c opt` the @@ -135,4 +135,4 @@ benchmark binary target on a quiescent machine. If you would like to detect when your benchmark test is running under the wrapper, call -[`Envoy::benchmark::skipExpensiveBechmarks()`](https://github.com/envoyproxy/envoy/blob/master/test/benchmark/main.h). +[`Envoy::benchmark::skipExpensiveBechmarks()`](https://github.com/envoyproxy/envoy/blob/main/test/benchmark/main.h). diff --git a/test/common/upstream/health_check_fuzz.cc b/test/common/upstream/health_check_fuzz.cc index 1d109d74bda4..d2e37392b296 100644 --- a/test/common/upstream/health_check_fuzz.cc +++ b/test/common/upstream/health_check_fuzz.cc @@ -304,7 +304,7 @@ void TcpHealthCheckFuzz::raiseEvent(const Network::ConnectionEvent& event_type, } // In the specific case of: - // https://github.com/envoyproxy/envoy/blob/master/source/common/upstream/health_checker_impl.cc#L489 + // https://github.com/envoyproxy/envoy/blob/main/source/common/upstream/health_checker_impl.cc#L489 // This blows away client, should create a new one if (event_type == Network::ConnectionEvent::Connected && empty_response_) { ENVOY_LOG_MISC(trace, "Will create client from connected event and empty response."); diff --git a/test/extensions/filters/network/common/fuzz/README.md b/test/extensions/filters/network/common/fuzz/README.md index 21181c8402a4..d35fb5d92dbc 100644 --- a/test/extensions/filters/network/common/fuzz/README.md +++ b/test/extensions/filters/network/common/fuzz/README.md @@ -1,2 +1,2 @@ -Network filters need to be fuzzed. Filters come in two flavors, each with their own fuzzer. Read filters should be added into the [Generic ReadFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz_test.cc). Write Filters should added into the [Generic WriteFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz_test.cc). Some filters are both raed and write filters: They should be added into both fuzzers. -To add a new filter into generic network level filter fuzzers, see the [doc](https://github.com/envoyproxy/envoy/blob/master/source/docs/network_filter_fuzzing.md). \ No newline at end of file +Network filters need to be fuzzed. Filters come in two flavors, each with their own fuzzer. Read filters should be added into the [Generic ReadFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz_test.cc). Write Filters should added into the [Generic WriteFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz_test.cc). Some filters are both raed and write filters: They should be added into both fuzzers. +To add a new filter into generic network level filter fuzzers, see the [doc](https://github.com/envoyproxy/envoy/blob/main/source/docs/network_filter_fuzzing.md). \ No newline at end of file diff --git a/test/integration/stats_integration_test.cc b/test/integration/stats_integration_test.cc index f2b7bee41230..7a6981a5d9a3 100644 --- a/test/integration/stats_integration_test.cc +++ b/test/integration/stats_integration_test.cc @@ -279,7 +279,7 @@ TEST_P(ClusterMemoryTestRunner, MemoryLargeClusterSize) { // vary. // // If you encounter a failure here, please see - // https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#stats-memory-tests + // https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#stats-memory-tests // for details on how to fix. // // We only run the exact test for ipv6 because ipv4 in some cases may allocate a @@ -325,7 +325,7 @@ TEST_P(ClusterMemoryTestRunner, MemoryLargeHostSizeWithStats) { // at the logs. // // If you encounter a failure here, please see - // https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#stats-memory-tests + // https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#stats-memory-tests // for details on how to fix. // // We only run the exact test for ipv6 because ipv4 in some cases may allocate a diff --git a/tools/api/generate_go_protobuf.py b/tools/api/generate_go_protobuf.py index 5b25de2dbb0a..23ef195c84cd 100755 --- a/tools/api/generate_go_protobuf.py +++ b/tools/api/generate_go_protobuf.py @@ -16,7 +16,7 @@ IMPORT_BASE = 'github.com/envoyproxy/go-control-plane' OUTPUT_BASE = 'build_go' REPO_BASE = 'go-control-plane' -BRANCH = 'master' +BRANCH = 'main' MIRROR_MSG = 'Mirrored from envoyproxy/envoy @ ' USER_NAME = 'go-control-plane(Azure Pipelines)' USER_EMAIL = 'go-control-plane@users.noreply.github.com' diff --git a/tools/git/last_github_commit.sh b/tools/git/last_github_commit.sh index 9746d259ac3b..2ca2fb0fda29 100755 --- a/tools/git/last_github_commit.sh +++ b/tools/git/last_github_commit.sh @@ -1,8 +1,8 @@ #!/bin/bash -# Looking back from HEAD, find the first commit that was merged onto master by GitHub. This is +# Looking back from HEAD, find the first commit that was merged onto main by GitHub. This is # likely the last non-local change on a given branch. There may be some exceptions for this -# heuristic, e.g. when patches are manually merged for security fixes on master, but this is very +# heuristic, e.g. when patches are manually merged for security fixes on main, but this is very # rare. git rev-list --no-merges --committer="GitHub " --max-count=1 HEAD diff --git a/tools/proto_format/proto_sync.py b/tools/proto_format/proto_sync.py index f6fc70a13a66..adbaa011257d 100755 --- a/tools/proto_format/proto_sync.py +++ b/tools/proto_format/proto_sync.py @@ -433,7 +433,7 @@ def Sync(api_root, mode, labels, shadow): if deleted_files: print('The following files will be deleted: %s' % sorted(deleted_files)) print( - 'If this is not intended, please see https://github.com/envoyproxy/envoy/blob/master/api/STYLE.md#adding-an-extension-configuration-to-the-api.' + 'If this is not intended, please see https://github.com/envoyproxy/envoy/blob/main/api/STYLE.md#adding-an-extension-configuration-to-the-api.' ) if input('Delete files? [yN] ').strip().lower() == 'y': subprocess.run(['patch', '-p1'], input=diff, cwd=str(api_root_path.resolve()))