build(deps): bump the examples-golang-network group across 1 directory with 2 updates

[dependabot]

Bumps the examples-golang-network group with 2 updates in the /golang-network/simple directory: github.com/envoyproxy/envoy and google.golang.org/protobuf.

Updates github.com/envoyproxy/envoy from 1.32.3 to 1.33.0

Release notes

Sourced from github.com/envoyproxy/envoy's releases.

v1.33.0

Summary of changes:

• c-ares:
  • CVE-2024-25629 Out of bounds read in c-ares (DNS)
• HTTP:
  • RFC1918 addresses are no longer considered to be internal addresses by default. This addresses a security issue for Envoys in multi-tenant mesh environments.
  • Shadow requests are now streamed in parallel with the original request.
  • Local replies now traverse the filter chain if 1xx headers have been sent to the client.
• Tracing:
  • Removed support for (long deprecated) Opencensus tracing extension.
• Wasm:
  • The route cache will not be cleared by default if a Wasm extension modifies the request headers and the ABI version of wasm extension is larger than 0.2.1.
  • Remove previously deprecated xDS attributes from get_property, use xds attributes instead.
  • Added Wasm VM reload support and support for plugins writtin in Go.
• Access log:
  • New implementation of the JSON formatter is enabled by default.
• CSRF:
  • Increase the statistics counter missing_source_origin only for requests with a missing source origin.
• DNS:
  • Added nameserver rotation and query timeouts/retries to the c-ares resolver.
• Formatter:
  • NaN and Infinity values of float will be serialized to null and inf respectively in the metadata (DYNAMIC_METADATA, CLUSTER_METADATA, etc.) formatters.
• OAuth2:
  • use_refresh_token is now enabled by default.
  • Implement the Signed Double-Submit Cookie pattern.
• QUIC:
  • Enable UDP GRO in QUIC client connections by default.
• SDS:
  • Relaxed the backing cluster validation for Secret Discovery Service (SDS).
• TLS:
  • Added support for P-384 and P-521 curves for server certificates, improved upstream SNI and SAN validation support.

Docker images: https://hub.docker.com/r/envoyproxy/envoy/tags?page=1&name=v1.33.0 Docs: https://www.envoyproxy.io/docs/envoy/v1.33.0/ Release notes: https://www.envoyproxy.io/docs/envoy/v1.33.0/version_history/v1.33/v1.33.0 Full changelog: envoyproxy/envoy@v1.32.0...v1.33.0

Changelog

Sourced from github.com/envoyproxy/envoy's changelog.

Release Process

Active development

Active development is happening on the main branch, and a new version is released from it.

Stable releases

Stable releases of Envoy include:

• Major releases in which a new version a created directly from the main branch.
• Minor releases for versions covered by the extended maintenance window (any version released in the last 12 months).
  • Security fixes backported from the main branch (including those deemed not worthy of creating a CVE).
  • 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.

Major releases happen quartely and follow the schedule below. Security fixes typically happen quarterly as well, but this depends on the number and severity of security bugs. Other releases are ad-hoc and best-effort.

Security releases

Critical security fixes are owned by the Envoy security team, which provides fixes for the main branch. Once those fixes are ready, the maintainers of stable releases backport them to the remaining supported stable releases.

Backports

All other security and reliability fixes can be nominated for backporting to stable releases by Envoy maintainers, Envoy security team, the change author, or members of the Envoy community by adding the backport/review or backport/approved label (this can be done using [repokitteh]'s /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 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.

Release management

Major releases are handled by the maintainer on-call and do not involve any backports. The details are outlined in the "Cutting a major release" section below. Security releases are handled by a Release Manager and a Fix Lead. The Release Manager is responsible for approving and merging backports, with responsibilties outlined in https://github.com/envoyproxy/envoy/blob/main/BACKPORTS.md. The Fix Lead is a member of the security team and is responsible for coordinating the overall release. This includes identifying issues to be fixed in the release, communications with the Envoy community, and the

... (truncated)

Commits

• b0f43d6 repo: Release v1.33.0
• c93cf7a changelogs: Release summary cleanups (#38001)
• 078dae3 ratelimit-docs: fix the RLS proto docs for skip_if_absent fields (#37997)
• 7b20933 ci/deps: Bump gh-actions -> 0.3.15 (#37980)
• 03cb8d5 build(deps): bump google.golang.org/protobuf
• 3487b22 build(deps): bump google.golang.org/protobuf
• acdcfc6 build(deps): bump orjson from 3.10.13 to 3.10.14 in /tools/base
• 02633ec build(deps): bump protobuf from 5.29.2 to 5.29.3 in /tools/base
• e62004f build(deps): bump setuptools from 75.6.0 to 75.8.0 in /tools/base
• 62c18d7 build(deps): bump pyopenssl from 24.3.0 to 25.0.0 in /tools/base
• Additional commits viewable in compare view

Updates google.golang.org/protobuf from 1.36.2 to 1.36.3

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions