diff --git a/VERSION.txt b/VERSION.txt index d958a2c6744e..26a9e99b38be 100644 --- a/VERSION.txt +++ b/VERSION.txt @@ -1 +1 @@ -1.25.4-dev +1.25.4 diff --git a/changelogs/1.22.10.yaml b/changelogs/1.22.10.yaml new file mode 100644 index 000000000000..890888ef8553 --- /dev/null +++ b/changelogs/1.22.10.yaml @@ -0,0 +1,28 @@ +date: April 4, 2023 + +behavior_changes: +- area: http + change: | + validate upstream request header names and values. The new runtime flag ``envoy.reloadable_features.validate_upstream_headers`` can be used for revert this behavior. + +bug_fixes: +- area: grpc + change: | + when Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding the protobuf message. For ext_authz that was configured with ``failure_mode_allow: true``, the request would have been allowed in this case. For the other services, this could have resulted in other unforseen errors such as a lack of visibility into requests (eg request not logged). Envoy will now by default sanitize the values sent in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a '!' character. This behavioral change can be temporarily reverted by setting runtime guard ``envoy.reloadable_features.service_sanitize_non_utf8_strings`` to false. +- area: http + change: | + fixed a bug where ``x-envoy-original-path`` was not being sanitized when sent from untrusted users. This behavioral change can be temporarily reverted by setting ``envoy.reloadable_features.sanitize_original_path`` to false. +- area: http + change: | + stop forwarding ``:method`` value which is not a valid token defined in https://www.rfc-editor.org/rfc/rfc9110#section-5.6.2. + Also, reject ``:method`` and ``:scheme`` headers with multiple values. +- area: http3 + change: | + reject pseudo headers violating RFC 9114. Specifically, pseudo-header fields with more than one value for the ``:method`` (non-``CONNECT``), + ``:scheme``, and ``:path``; or pseudo-header fields after regular header fields; or undefined pseudo-headers. +- area: lua + change: | + lua coroutine should not execute after local reply is sent. +- area: oauth + change: | + fixed a bug where the oauth2 filter would crash if it received a redirect URL without a state query param set. diff --git a/changelogs/1.23.7.yaml b/changelogs/1.23.7.yaml new file mode 100644 index 000000000000..cd03b53fcfd4 --- /dev/null +++ b/changelogs/1.23.7.yaml @@ -0,0 +1,33 @@ +date: April 4, 2023 + +behavior_changes: +- area: http + change: | + Validate upstream request header names and values. The new runtime flag ``envoy.reloadable_features.validate_upstream_headers`` can be used for revert this behavior. + +bug_fixes: +- area: oauth2 + change: | + fixed a bug where the oauth2 filter would crash if it received a redirect URL without a state query param set. +- area: lua + change: | + lua coroutine should not execute after local reply is sent. +- area: grpc + change: | + When Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, + Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding + the protobuf message. For ext_authz that was configured with ``failure_mode_allow: true``, the request would have been allowed in this case. For the other services, this + could have resulted in other unforseen errors such as a lack of visibility into requests (eg request not logged). Envoy will now by default sanitize the values sent + in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a '!' character. This behavioral change can be temporarily reverted by + setting runtime guard ``envoy.reloadable_features.service_sanitize_non_utf8_strings`` to false. +- area: http + change: | + stop forwarding ``:method`` value which is not a valid token defined in https://www.rfc-editor.org/rfc/rfc9110#section-5.6.2. + Also, reject ``:method`` and ``:scheme`` headers with multiple values. +- area: http3 + change: | + reject pseudo headers violating RFC 9114. Specifically, pseudo-header fields with more than one value for the ``:method`` (non-``CONNECT``), + ``:scheme``, and ``:path``; or pseudo-header fields after regular header fields; or undefined pseudo-headers. +- area: http + change: | + fixed a bug where ``x-envoy-original-path`` was not being sanitized when sent from untrusted users. This behavioral change can be temporarily reverted by setting ``envoy.reloadable_features.sanitize_original_path`` to false. diff --git a/changelogs/1.24.5.yaml b/changelogs/1.24.5.yaml new file mode 100644 index 000000000000..71ab3dd81075 --- /dev/null +++ b/changelogs/1.24.5.yaml @@ -0,0 +1,33 @@ +date: April 5, 2023 + +behavior_changes: +- area: http + change: | + Validate upstream request header names and values. The new runtime flag ``envoy.reloadable_features.validate_upstream_headers`` can be used for revert this behavior. + +bug_fixes: +- area: oauth2 + change: | + fixed a bug where the oauth2 filter would crash if it received a redirect URL without a state query param set. +- area: lua + change: | + lua coroutine should not execute after local reply is sent. +- area: grpc + change: | + When Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, + Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding + the protobuf message. For ext_authz that was configured with ``failure_mode_allow: true``, the request would have been allowed in this case. For the other services, this + could have resulted in other unforseen errors such as a lack of visibility into requests (eg request not logged). Envoy will now by default sanitize the values sent + in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a '!' character. This behavioral change can be temporarily reverted by + setting runtime guard ``envoy.reloadable_features.service_sanitize_non_utf8_strings`` to false. +- area: http + change: | + stop forwarding ``:method`` value which is not a valid token defined in https://www.rfc-editor.org/rfc/rfc9110#section-5.6.2. + Also, reject ``:method`` and ``:scheme`` headers with multiple values. +- area: http3 + change: | + reject pseudo headers violating RFC 9114. Specifically, pseudo-header fields with more than one value for the ``:method`` (non-``CONNECT``), + ``:scheme``, and ``:path``; or pseudo-header fields after regular header fields; or undefined pseudo-headers. +- area: http + change: | + fixed a bug where ``x-envoy-original-path`` was not being sanitized when sent from untrusted users. This behavioral change can be temporarily reverted by setting ``envoy.reloadable_features.sanitize_original_path`` to false. diff --git a/changelogs/current.yaml b/changelogs/current.yaml index 24d01b19305e..71ab3dd81075 100644 --- a/changelogs/current.yaml +++ b/changelogs/current.yaml @@ -1,16 +1,11 @@ -date: Pending +date: April 5, 2023 behavior_changes: -# *Changes that are expected to cause an incompatibility if applicable; deployment changes are likely required* - area: http change: | Validate upstream request header names and values. The new runtime flag ``envoy.reloadable_features.validate_upstream_headers`` can be used for revert this behavior. -minor_behavior_changes: -# *Changes that may cause incompatibilities for some users, but should not for most* - bug_fixes: -# *Changes expected to improve the state of the world and are unlikely to have negative effects* - area: oauth2 change: | fixed a bug where the oauth2 filter would crash if it received a redirect URL without a state query param set. @@ -36,10 +31,3 @@ bug_fixes: - area: http change: | fixed a bug where ``x-envoy-original-path`` was not being sanitized when sent from untrusted users. This behavioral change can be temporarily reverted by setting ``envoy.reloadable_features.sanitize_original_path`` to false. - -removed_config_or_runtime: -# *Normally occurs at the end of the* :ref:`deprecation period ` - -new_features: - -deprecated: diff --git a/docs/inventories/v1.22/objects.inv b/docs/inventories/v1.22/objects.inv index 418d07e65144..cc6a587fd5ef 100644 Binary files a/docs/inventories/v1.22/objects.inv and b/docs/inventories/v1.22/objects.inv differ diff --git a/docs/inventories/v1.23/objects.inv b/docs/inventories/v1.23/objects.inv index f688874e2c09..699320d52db1 100644 Binary files a/docs/inventories/v1.23/objects.inv and b/docs/inventories/v1.23/objects.inv differ diff --git a/docs/inventories/v1.24/objects.inv b/docs/inventories/v1.24/objects.inv index 4aac45db17f8..2ce204ee4f56 100644 Binary files a/docs/inventories/v1.24/objects.inv and b/docs/inventories/v1.24/objects.inv differ diff --git a/docs/inventories/v1.25/objects.inv b/docs/inventories/v1.25/objects.inv index 7d7ce20cce71..98b112e79c45 100644 Binary files a/docs/inventories/v1.25/objects.inv and b/docs/inventories/v1.25/objects.inv differ diff --git a/docs/versions.yaml b/docs/versions.yaml index c0c83e864fd4..65d6d9189ca7 100644 --- a/docs/versions.yaml +++ b/docs/versions.yaml @@ -15,7 +15,7 @@ "1.19": 1.19.5 "1.20": 1.20.7 "1.21": 1.21.6 -"1.22": 1.22.9 -"1.23": 1.23.6 -"1.24": 1.24.4 -"1.25": 1.25.2 +"1.22": 1.22.10 +"1.23": 1.23.7 +"1.24": 1.24.5 +"1.25": 1.25.3