-
Notifications
You must be signed in to change notification settings - Fork 619
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
[RFC] Caller-side managed buffers #1420
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1420 +/- ##
==========================================
+ Coverage 96.34% 96.50% +0.16%
==========================================
Files 64 71 +7
Lines 14808 15124 +316
==========================================
+ Hits 14267 14596 +329
+ Misses 541 528 -13 see 51 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Stream API still needs to be updated
I have started working on revising the RFC to meet this design goal. the work is visible in this WIP branch. when I'm done there, I'll push the changes into this branch / PR |
switch main proposal to use the enum alternative to a Status struct that only contains boolean flags
The RFC has been updated:
|
} | ||
|
||
/// Encrypts `app_data` into the `outgoing_tls` buffer | ||
pub fn encrypt_outgoing(&self, app_data: &[u8], outgoing_tls: &mut Vec<u8>) { /* .. */ } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto.
pub fn decrypt_incoming<'a, B>( | ||
&self, | ||
incoming_tls: &'a mut IncomingTls<B>, | ||
) -> impl Iterator<Item = Result<&'a [u8]>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a GAT-based LendingIterator
?
`State`, and thus `Status` as well, would have to gain a lifetime that ties it to the `incoming_tls` buffer. | ||
Given how Rust works, even if `State` was not in the `ReceivedEarlyData` variant, the `status.state` field would still "freeze" `incoming_tls` meaning that it can't be mutated until `status.state` goes out of scope / is dropped. | ||
|
||
The other issues is that if `process_tls_records` automatically decrypts early data, the end-user no longer has the option to discard the early data without decrypting it first (see snippet below) to save some CPU work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this could be offered as a method.
BTW, one goal to keep in mind is code reuse across the high-level and low-level API. So ideally the high-level API can be implemented on top of the low-level API to avoid duplicating logic. |
and test with mocked async IO and blocking read_buf API
the sketch2 crate has been updated and now includes the certification validation API. two mocked examples / tests are included: one uses mocked async IO; the other one uses libstd's the sketch2 implements this idea of making certain operations possible only when certain conditions are met thus making the API statically impossible to misuse. I also went ahead and experimented with turning |
Another important point to me at least is that the library cannot issue allocations (via resizing the |
re-implement Stream on top of LlClientConnection for testing purposes
I've updated what I realized while implementing OR, if it's always possible to |
the RFC text has been update to use "sketch2" as the main proposal. the this is ready for a new review / round of comments! |
Going to close this. We have some follow-on work in other issues, but the initial version of this was delivered in 0.23. |
|
Summary
This RFC proposes adding a new, lower-level
{Client,Server}Connection
API where TLS and plain-text buffers are managed by the caller / end-user.The design goals of this new API are to reduce / minimize memcpys, be no-std compatible and allow
async
certificate verification.Rendered version
This RFC addresses issue #1362
Also check out the mock implementation of the proposed API in the PR branch
This aspect still needs more work but I think the main part that addresses #1362 is ready for comments!this section is now complete