grpc-uds: update to 0.3.18 #2

nightkr · 2023-04-19T13:38:37Z

No description provided.

…#586) This makes reading the logs way easier on the eyes.

Found by oss-fuzz

We have reports of runtime panics (linkerd/linkerd2#7748) that sound a lot like rust-lang/rust#86470. We don't have any evidence that these panics originate in h2, but there is one use of `Instant::sub` that could panic in this way. Even though this is almost definitely a bug in Rust, it seems most prudent to actively avoid the uses of `Instant` that are prone to this bug. These fixes should ultimately be made in the standard library, but this change lets us avoid this problem while we wait for those fixes. This change replaces uses of `Instant::elapsed` and `Instant::sub` with calls to `Instant::saturating_duration_since` to prevent this class of panic. See also hyperium/hyper#2746

…h decoded Decoding error when processing continuation header which contains normal header name at boundary

## Motivation Currently, the `tracing` spans for the client and server handshakes contain the name of the I/O type. In some cases, where nested I/O types are in use, these names can be quite long; for example, in Linkerd, we see log lines like this: ``` 2022-03-07T23:38:15.322506670Z [ 10533.916262s] DEBUG ThreadId(01) inbound:accept{client.addr=192.168.1.9:1227}:server{port=4143}:direct:gateway{dst=server.echo.svc.cluster.local:8080}:server_handshake{io=hyper::common::io::rewind::Rewind<linkerd_io::either::EitherIo<linkerd_io::sensor::SensorIo<linkerd_io::prefixed::PrefixedIo<linkerd_io::either::EitherIo<tokio_rustls::server::TlsStream<linkerd_io::either::EitherIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>, linkerd_io::prefixed::PrefixedIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>>>>, linkerd_io::either::EitherIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>, linkerd_io::prefixed::PrefixedIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>>>>>, linkerd_transport_metrics::sensor::Sensor>, linkerd_io::sensor::SensorIo<linkerd_io::either::EitherIo<tokio_rustls::server::TlsStream<linkerd_io::either::EitherIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>, linkerd_io::prefixed::PrefixedIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>>>>, linkerd_io::either::EitherIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>, linkerd_io::prefixed::PrefixedIo<linkerd_io::scoped::ScopedIo<tokio::net::tcp::stream::TcpStream>>>>, linkerd_transport_metrics::sensor::Sensor>>>}:FramedWrite::buffer{frame=Settings { flags: (0x0), initial_window_size: 65535, max_frame_size: 16384 }}: h2::codec::framed_write: send frame=Settings { flags: (0x0), initial_window_size: 65535, max_frame_size: 16384 } ``` which is kinda not great. ## Solution This branch removes the IO type's type name from the spans for the server and client handshakes. In practice, these are not particularly useful, because a given server or client instance is parameterized over the IO types and will only serve connections of that type.

# 0.3.12 (March 9, 2022) * Avoid time operations that can panic (hyperium#599) * Bump MSRV to Rust 1.49 (hyperium#606) * Fix header decoding error when a header name is contained at a continuation header boundary (hyperium#589) * Remove I/O type names from handshake `tracing` spans (hyperium#608)

Nightly has begun running doctests for unexported macros as of rust-lang/rust#96630, which caused a doctest for test_unpack_octets_4 which was previously ignored to be run. This broke the CI because macros that are not exported with `#[macro_export]` cannot be used from external crates (and thus cannot be doctested). This change ignores the doctest and copies the relevant code into a unit test. Co-authored-by: David Koloski <[email protected]>

Signed-off-by: Ryan Russell <[email protected]>

Signed-off-by: Miguel Guarniz <[email protected]>

…yperium#634) Http2 Server are allowed to early respond without fully consuming client input stream, but must respond with an error code of NO_ERROR when sending RST_STREAM. Nginx treat any other error code as fatal if not done so Commit change error code from CANCEL to NO_ERROR, when the server is early responding to the client hyperium#633 https://trac.nginx.org/nginx/ticket/2376

Remove redundant and misleading phrase in client::Builder::enable_push documentation. Resolves hyperium#645

Co-authored-by: p00512853 <[email protected]>

This exposes the :protocol pseudo header as Request extension. Fixes hyperium#347

…am (hyperium#657) We met the panic in our production environment, so handle this panic condition before panic. The stack backtrace: Co-authored-by: winters.zc <[email protected]>

…m#661) Fixes hyperium#628 Sometimes `poll_capacity` returns `Ready(Some(0))` - in which case caller will have no way to wait for the stream capacity to become available. The previous attempt on the fix has addressed only a part of the problem. The root cause - in a nutshell - is the race condition between the application tasks that performs stream I/O and the task that serves the underlying HTTP/2 connection. The application thread that is about to send data calls `reserve_capacity/poll_capacity`, is provided with some send capacity and proceeds to `send_data`. Meanwhile the service thread may send some buffered data and/or receive some window updates - either way the stream's effective allocated send capacity may not change, but, since the capacity still available, `send_capacity_inc` flag may be set. The sending task calls `send_data` and uses the entire allocated capacity, leaving the flag set. Next time `poll_capacity` returns `Ready(Some(0))`. This change sets the flag and dispatches the wakeup event only in cases when the effective capacity reported by `poll_capacity` actually increases.

It's quite confusing from production logs when all I get is "broken pipe" and I don't know which path was taken for that error to be logged.

Streams that have been received by the peer, but not accepted by the user, can also receive a RST_STREAM. This is a legitimate pattern: one could send a request and then shortly after, realize it is not needed, sending a CANCEL. However, since those streams are now "closed", they don't count towards the max concurrent streams. So, they will sit in the accept queue, using memory. In most cases, the user is calling `accept` in a loop, and they can accept requests that have been reset fast enough that this isn't an issue in practice. But if the peer is able to flood the network faster than the server accept loop can run (simply accepting, not processing requests; that tends to happen in a separate task), the memory could grow. So, this introduces a maximum count for streams in the pending-accept but remotely-reset state. If the maximum is reached, a GOAWAY frame with the error code of ENHANCE_YOUR_CALM is sent, and the connection marks itself as errored. ref CVE-2023-26964 ref GHSA-f8vr-r385-rh5r Closes hyperium/hyper#2877

The new option is available to both client and server `Builder`s.

stackable-bot · 2023-04-19T13:38:46Z

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 23 committers have signed the CLA.

✅ djc
❌ seanmonstar
❌ nox
❌ LPardue
❌ olix0r
❌ hikaricai
❌ hawkw
❌ djkoloski
❌ bruceg
❌ ryanrussell
❌ kckeiks
❌ erebe
❌ LucioFranco
❌ ehaydenr
❌ vi
❌ silence-coding
❌ gtsiam
❌ howardjohn
❌ cloneable
❌ aftersnow
❌ vadim-eg
❌ atouchet
❌ nickelc
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

nightkr · 2023-04-19T13:41:47Z

Excluded CLAbot from this repo since it's not a Stackable Product.

lfrancke

Uhhhmm yes! I took a close look and approve!

# Description Depends on stackabletech/h2#2. Replaces #67. Should also be replicated in secret-op once merged.

seanmonstar and others added 30 commits November 23, 2021 10:32

fix: properly reject prioritized HEADERS with stream ID of zero

dbaa3a4

Implement the extended CONNECT protocol from RFC 8441 (hyperium#565)

87969c1

Add test that would make wait_for_capacity hang if it doesn't loop

e9e0f27

Add max send buffer per stream option (hyperium#580)

efa113b

v0.3.8

88037ae

Fix poll_capacity to wake in combination with max_send_buffer_size

a5c60b2

v0.3.9

308663e

Fix panic when receiving malformed push promise with stream id 0

c876dda

Add Error::is_go_away() and Error::is_remote()

6336cc3

v0.3.10

b949d6e

Make SendStream::poll_capacity never return Ok(Some(0)) (hyperium#596)

d92ba1c

Fixes hyperium#270

Update tracing-subscriber and use tracing-tree when testing (hyperium…

a28a39c

…#586) This makes reading the logs way easier on the eyes.

fix panic when receiving already reset push promise (hyperium#597)

7de2ccc

Found by oss-fuzz

Make use of NLL to clean up handshaking logic (hyperium#576)

556447c

v0.3.11

b0d01bb

There's no such thing as HTTP/2.0

47e9f62

Upgrade dev-dependencies

4c31a32

Bump MSRV to 1.49, since Tokio uses it

7bb1462

fix header parsing: consume buf only if header name and value are bot…

85549fc

…h decoded Decoding error when processing continuation header which contains normal header name at boundary

Upgrade tokio-util to 0.7

a54d926

v0.3.13

3a0c622

Add Error::is_reset function (hyperium#618)

f6aa3be

Fix Typo received (hyperium#620)

e4cf88c

Signed-off-by: Ryan Russell <[email protected]>

Bump MSRV to 1.56 (hyperium#626)

fd4040d

Replace internal PollExt trait with Poll inherent methods (hyperium#625)

756384f

Signed-off-by: Miguel Guarniz <[email protected]>

vi and others added 20 commits October 29, 2022 14:22

Fix docs of enable_push (hyperium#646)

294000c

Remove redundant and misleading phrase in client::Builder::enable_push documentation. Resolves hyperium#645

fix issue#648: drop frame if stream is released (hyperium#651)

af47a08

Co-authored-by: p00512853 <[email protected]>

Remove unnecessary Unpin + 'static bounds on body (hyperium#649)

c1ce37e

Fix all clippy warnings (hyperium#652)

07d20b1

Consistently indicate malformed in logs (hyperium#658)

68e4403

Add Protocol extension to Request on Extended CONNECT (hyperium#655)

b84c244

This exposes the :protocol pseudo header as Request extension. Fixes hyperium#347

fix: panic in when there is connection window available, but not stre…

73bea23

…am (hyperium#657) We met the panic in our production environment, so handle this panic condition before panic. The stack backtrace: Co-authored-by: winters.zc <[email protected]>

Add a message for EOF-related broken pipe errors (hyperium#615)

96caf4f

It's quite confusing from production logs when all I get is "broken pipe" and I don't know which path was taken for that error to be logged.

v0.3.16

b9dcd39

chore: set rust-version in Cargo.toml (hyperium#664)

45b9bcc

chore: Replace unmaintained/outdated GitHub Actions

d3d50ef

chore: Use Cargo metadata for the MSRV build job

481c31d

feat: add Error::is_library method

8088ca6

feat: add max_pending_accept_reset_streams(n) options

d3f37e9

The new option is available to both client and server `Builder`s.

v0.3.17

af4bcac

fix: pending-accept remotely-reset streams pattern was checking is_local

1c6fa28

v0.3.18

1b9f070

Merge tag 'v0.3.18' into feature/grpc-uds

614e04b

nightkr requested review from lfrancke and a team April 19, 2023 13:38

nightkr mentioned this pull request Apr 19, 2023

[Merged by Bors] - Update h2 to 0.3.18 stackabletech/listener-operator#69

Closed

lfrancke approved these changes Apr 19, 2023

View reviewed changes

nightkr merged commit 557dd10 into feature/grpc-uds Apr 19, 2023

nightkr deleted the feature/grpc-uds-/0.3.18 branch April 19, 2023 13:42

bors bot pushed a commit to stackabletech/listener-operator that referenced this pull request Apr 19, 2023

Update h2 to 0.3.18 (#69)

dcf542c

# Description Depends on stackabletech/h2#2. Replaces #67. Should also be replicated in secret-op once merged.

nightkr mentioned this pull request May 8, 2024

Update to h2 v0.3.13 #1

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

grpc-uds: update to 0.3.18 #2

grpc-uds: update to 0.3.18 #2

nightkr commented Apr 19, 2023

stackable-bot commented Apr 19, 2023 •

edited

Loading

nightkr commented Apr 19, 2023

lfrancke left a comment

grpc-uds: update to 0.3.18 #2

grpc-uds: update to 0.3.18 #2

Conversation

nightkr commented Apr 19, 2023

stackable-bot commented Apr 19, 2023 • edited Loading

nightkr commented Apr 19, 2023

lfrancke left a comment

Choose a reason for hiding this comment

stackable-bot commented Apr 19, 2023 •

edited

Loading