merge envoy/release/v1.34:4ee84e441c13f8cfbf5b3cfd22f99569121ba33b to envoy-openssl/release/v1.34 #339
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ewrite and matching (#39169) Adds support for matching requests that include the `*` character in the path. A relevant issue was created: envoyproxy/envoy#39168 Risk Level: Testing: Updated unit tests Docs Changes: N/A Release Notes: Added Platform Specific Features: N/A Runtime guard: envoy.reloadable_features.uri_template_match_on_asterisk Resolves: envoyproxy/envoy#39168 --------- Signed-off-by: Chwila <[email protected]> Signed-off-by: Yan Avlasov <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
**Docker images**:
https://hub.docker.com/r/envoyproxy/envoy/tags?page=1&name=v1.34.1
**Docs**:
https://www.envoyproxy.io/docs/envoy/v1.34.1/
**Release notes**:
https://www.envoyproxy.io/docs/envoy/v1.34.1/version_history/v1.34/v1.34.1
**Full changelog**:
envoyproxy/envoy@v1.34.0...v1.34.1
Signed-off-by: Ryan Northey <[email protected]>
Backport #39310 and #39349 If a connection starts draining while it has negative unused capacity (which happens if a SETTINGS frame reduces allowed concurrency to below the current number of requests), that connections unused capacity will be included in total pool capacity even though it is unusable because it is draining. This can result in not enough connections being established for current pending requests. This is most problematic for long-lived requests (such as streaming gRPC requests or long-poll requests) because a connection could be in the draining state for a long time. Maybe fixes: #39238 Fixed an issue that could lead to too many connections when using :ref:`AutoHttpConfig <envoy_v3_api_msg_extensions.upstreams.http.v3.HttpProtocolOptions.AutoHttpConfig>` if the established connection is ``http/2`` and Envoy predicted it would have lower concurrent capacity. --------- Signed-off-by: Greg Greenway <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
Static linking helps to work around the issue with LLVM/Clang source-based coverage (see llvm/llvm-project#32849). On the flip side, the coverage build and test run will take a bit longer (e.g., around 30m) with this change. This PR switches to static linking for just test coverage and does not do the same for fuzz coverage. That's because Envoy CI is hitting some resource constraints when building fuzz targets with coverage instrumentation. We will fix that by striping the fuzz targets of some unncessary dependencies and switching to EngFlow backend for coverage builds and tests, but that will require addressing a couple of hard to understand issues, so, for now, I'm just switching the coverage tests to static linking and will follow up with the fuzz tests later once we addressed all the blockers and switched to EngFlow backend for coverage. Additional Description: envoyproxy/envoy#39030 provides some context for EngFlow migration and envoyproxy/envoy#39248 is a tracking bug. Signed-off-by: Mikhail Krinkin <[email protected]> Signed-off-by: Ryan Northey <[email protected]>
Commit Message: Simple grep over the codebase suggests that we don't have any WASM specific fuzz tests defined. And existing fuzz tests don't need a full WASM runtime. On top of that in general we don't really want to fuzz test our dependencies (e.g., we would like the dependencies to have their own infrastructure and be scrupulous when new dependencies are added). Disabling WASM reduces the build time and resources required for fuzz-coverage. One particular reason to try and optimize fuzz-coverage is that I want to move it to static linking to work around a bug in Clang/LLVM (see llvm/llvm-project#32849) and static linking produces much large binaries and requires a larger linker footprint, which currently hits the limits of the RBE backend used. Additional Description: Some relevant discussions can be found in envoyproxy/envoy#39030 which prompted me to work on this in the first place. And I will use envoyproxy/envoy#39248 as a tracking bug for the coverage changes. Risk Level: low Testing: running fuzz-coverage on local machine with the changes included, I also confirmed that disabling wasm + moving fuzz-coverage to EngFlow + removing explicit RBE pool attributes from fuzz targets make it possible to successfully statically link fuzz tests Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a --------- Signed-off-by: Mikhail Krinkin <[email protected]> Signed-off-by: Ryan Northey <[email protected]>
Static linking helps to work around the issue with LLVM/Clang source-based coverage (see llvm/llvm-project#32849). On the flip side, the coverage build and test run will take a bit longer with this change. We already did this change for the regular test coverage, but we delayed the switch for the fuzz coverage because fuzz coverage hit RBE backend resource constraints and was OOMing during linking. Since then we did a few things to mitigate the issue with resources: 1. We switched coverage runs from Google RBE backend to EngFlow which allows for somewhat larger workers 2. We started building fuzz targets without WASM - there are not fuzz targets that actually need a full WASM runtime and elimnating it speeds things up and reduces the footprint noticably. With the above two changes I think we are ready to completely switch to static linking for all coverage tests. It also has a benefit of better cache re-use since we will be linking both coverage and fuzz coverage targets statically. Additional Description: envoyproxy/envoy#39030 provides some context for EngFlow migration and envoyproxy/envoy#39248 is a tracking bug. Risk Level: low Testing: regular CI tests Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a Signed-off-by: Mikhail Krinkin <[email protected]> Signed-off-by: Ryan Northey <[email protected]>
Commit Message: Tests were somewhat non-deterministic in the sense that the lines of code that this test exercises depend on the environment and whether /sys/fs/cgroup/cpu/cpuacct.usage exists. This issue affected Envoy coverage tests when we tried to migrate them from Google RBE backend to EngFlow. The same test worked fine and produced 100% coverage for LinuxContainerCpuStatsReader on Google RBE backends, but when we migrated to EngFlow the coverage changed and triggered a coverage test failure. This PR refactors the test a bit to make sure that both CPU allocation CPU times files are always available and valid, unless the test explicitly overrides it. Signed-off-by: Mikhail Krinkin <[email protected]> Signed-off-by: Ryan Northey <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
Signed-off-by: Rohit Agrawal <[email protected]>
## Description This PR migrates everything to use the consistent `envoy_select_enable_http3` macro we have. --- **Commit Message:** quic: make the FIPS build macros consistent **Additional Description:** Make BUILD files consistent by using the recommended macro everywhere. **Risk Level:** Low **Testing:** CI **Docs Changes:** N/A **Release Notes:** N/A Signed-off-by: Rohit Agrawal <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
…vels (#40011) Cherry-pick of envoyproxy/envoy#39954 PR to fix envoyproxy/envoy#39142 for 1.34 branch On strict dns / logical dns resolutions if there are errors on the DNS resolution, the failure logs are getting written only when debug log level enabled and general logs are also in debug level. So, making the general/success logs in the trace level to suppress the general logs when user wants only error logs. Signed-off-by: kishor7007 <[email protected]>
Fix https://ubuntu.com/security/CVE-2025-4802 Signed-off-by: Ryan Northey <[email protected]>
Signed-off-by: Ryan Northey <[email protected]> Signed-off-by: Rohit Agrawal <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
…s (#39615) Can be disabled by setting ``envoy.restart_features.do_not_validate_http3_pseudo_headers`` to false. --------- Signed-off-by: Ryan Hamilton <[email protected]>
**Summary of changes:**
- Container update to resolve glibc vulnerabilities
- Minor fixes
**Docker images**:
https://hub.docker.com/r/envoyproxy/envoy/tags?page=1&name=v1.34.2
**Docs**:
https://www.envoyproxy.io/docs/envoy/v1.34.2/
**Release notes**:
https://www.envoyproxy.io/docs/envoy/v1.34.2/version_history/v1.34/v1.34.2
**Full changelog**:
envoyproxy/envoy@v1.34.1...v1.34.2
Signed-off-by: Ryan Northey <[email protected]>
If tls connection data was queried before it was available, and empty value was being incorrectly cached, preventing later calls from getting the correct value. One way this could be triggered was with an access log entry being emitted before the TLS peer certificate was received during the TLS handshake, which can be configured with tcp_proxy. Fixes #40137 Signed-off-by: Greg Greenway <[email protected]>
Commit Message: Backport #40220 Additional Description: Risk Level: Low Testing: Unit tests Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A [Optional Runtime guard:] [Optional Fixes #37983] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] Signed-off-by: Gerhard Stöbich <[email protected]> Signed-off-by: Joao Grassi <[email protected]> Co-authored-by: Gerhard Stöbich <[email protected]>
Fix #39421 Signed-off-by: Ryan Northey <[email protected]>
Fix envoyproxy/envoy#40207 --------- Signed-off-by: Ryan Northey <[email protected]>
Backport fix for #40085 Signed-off-by: Greg Greenway <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
Changelog for #40220 Signed-off-by: Ryan Northey <[email protected]>
Signed-off-by: Ryan Northey <[email protected]>
**Summary of changes**:
* TLS:
- Fixed incorrectly cached connection properties on TLS connections that could cause network RBAC filters to fail.
* HTTP/2:
- Fixed connection window buffer leak in oghttp2 that could cause connections to get stuck.
* Observability:
- Fixed division by zero bug in Dynatrace sampling controller.
* Release:
- Fixed permissions for distroless config directory.
- Updated container images (Ubuntu/distroless).
**Docker images**:
https://hub.docker.com/r/envoyproxy/envoy/tags?page=1&name=v1.34.3
**Docs**:
https://www.envoyproxy.io/docs/envoy/v1.34.3/
**Release notes**:
https://www.envoyproxy.io/docs/envoy/v1.34.3/version_history/v1.34/v1.34.3
**Full changelog**:
envoyproxy/envoy@v1.34.2...v1.34.3
Signed-off-by: Ryan Northey <[email protected]>
zmiklank
force-pushed
the
release-1.34-origin
branch
from
d7aeecd to
897ba65
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.