Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: kick-off 1.13.5 release. #12164

Merged
merged 1 commit into from
Jul 20, 2020

Conversation

PiotrSikora
Copy link
Contributor

Signed-off-by: Piotr Sikora piotrsikora@google.com

Signed-off-by: Piotr Sikora <piotrsikora@google.com>
@PiotrSikora PiotrSikora requested review from lambdai and lizan July 18, 2020 07:24
@PiotrSikora
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@PiotrSikora
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@PiotrSikora
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@PiotrSikora
Copy link
Contributor Author

//test/integration:api_listener_integration_test is consistently failing in release/v1.13 branch (both here and in #12168), so I'm going to stop re-kicking the CI...

Copy link
Contributor

@lambdai lambdai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lambdai
Copy link
Contributor

lambdai commented Jul 20, 2020

/assign lizan

@dio
Copy link
Member

dio commented Jul 20, 2020

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@PiotrSikora
Copy link
Contributor Author

@dio see my comment above: #12164 (comment)

@lizan
Copy link
Member

lizan commented Jul 20, 2020

I'll merge this first, can you cherry pick #10818 later?

@lizan lizan merged commit 0322b0b into envoyproxy:release/v1.13 Jul 20, 2020
@PiotrSikora
Copy link
Contributor Author

I'll merge this first, can you cherry pick #10818 later?

@lambdai ^^

istio-testing pushed a commit to istio/envoy that referenced this pull request Oct 8, 2020
* docs: kick-off 1.13.5 release. (envoyproxy#12164)

Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>

* Preserve LWS from the middle of HTTP1 header values that requ… (envoyproxy#12320)

[http1] Preserve LWS from the middle of HTTP1 header values that require multiple dispatch calls to process (envoyproxy#10886)

Correctly preserve linear whitespace in the middle of HTTP1 header values. The fix in 6a95a21 trimmed away both leading and trailing whitespace when accepting header value fragments which can result in inner LWS in header values being stripped away if the LWS lands at the beginning or end of a buffer slice.

Signed-off-by: Antonio Vicente <avd@google.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>

* http: header map security fixes for duplicate headers (#197) (#203)

Previously header matching did not match on all headers for
non-inline headers. This patch changes the default behavior to
always logically match on all headers. Multiple individual
headers will be logically concatenated with ',' similar to what
is done with inline headers. This makes the behavior effectively
consistent. This behavior can be temporary reverted by setting
the runtime value "envoy.reloadable_features.header_match_on_all_headers"
to "false".

Targeted fixes have been additionally performed on the following
extensions which make them consider all duplicate headers by default as
a comma concatenated list:
1) Any extension using CEL matching on headers.
2) The header to metadata filter.
3) The JWT filter.
4) The Lua filter.
Like primary header matching used in routing, RBAC, etc. this behavior
can be disabled by setting the runtime value
"envoy.reloadable_features.header_match_on_all_headers" to false.

Finally, the setCopy() header map API previously only set the first
header in the case of duplicate non-inline headers. setCopy() now
behaves similiarly to the other set*() APIs and replaces all found
headers with a single value. This may have had security implications
in the extauth filter which uses this API. This behavior can be disabled
by setting the runtime value
"envoy.reloadable_features.http_set_copy_replace_all_headers" to false.

Fixes https://github.com/envoyproxy/envoy-setec/issues/188

Signed-off-by: Matt Klein <mklein@lyft.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>

* fixed compile

Signed-off-by: Yuchen Dai <silentdai@gmail.com>

* fix test

Signed-off-by: Yuchen Dai <silentdai@gmail.com>

Co-authored-by: Piotr Sikora <piotrsikora@google.com>

Co-authored-by: Yuchen Dai <silentdai@gmail.com>
Co-authored-by: Piotr Sikora <piotrsikora@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants