Converge config_ktls_{client,server} bounds to AsRawFd + AsyncRead + Unpin
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- networking
Research direction
Locate config_ktls_client and config_ktls_server in the version 6.0.2 source and compare their generic bounds with the operations used in each body. Check the existing test suite and verify that both functions accept an IO type implementing AsRawFd, AsyncRead, and Unpin without the redundant bounds; done means the project still builds and tests pass.
Written by the indexing model from the issue text.
Description
The two config functions (in version 6.0.2) have identical bodies but inconsistent, over-constrained bounds:
config_ktls_server: IO: AsRawFd + AsyncRead + AsyncReadReady + AsyncWrite + Unpin
config_ktls_client: IO: AsRawFd + AsyncRead + AsyncWrite + Unpin
Neither body uses AsyncWrite or AsyncReadReady. The only IO-touching operations are:
drain(&mut stream)— needsAsyncRead + Unpinsetup_inner(io.as_raw_fd(), ...)— needsAsRawFdKtlsStream::new(io, drained)— needsAsRawFd
AsyncReadReady is never invoked inside either function (the only call site is CorkStream::poll_read_ready).
Proposal: converge both to the minimal set the bodies require:
where IO: AsRawFd + AsyncRead + Unpin,
This is a backward-compatible loosening.
In my use case, I have a wrapping IO type that impls AsRawFd + AsyncRead + Unpin but not AsyncReadReady can be passed to config_ktls_client today but is rejected by config_ktls_server purely on the redundant bound.
If AsyncReadReady was meant to guarantee the returned KtlsStream<IO> is usable as AsyncRead, that bound already lives on impl AsyncRead for KtlsStream<IO>. Maybe there is no need to duplicate it on the config function, and not on the client/server asymmetrically.
- Dominant language
- Rust
- Stars
- 98
- Forks
- 17
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rustls/ktls
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
-
Add musl support Open
Difficulty 3/5 1-2 days Newbie friendliness 48/100
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
bitcoindevkit/bdk-ffi#1125 ·