-
Notifications
You must be signed in to change notification settings - Fork 183
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
TLS Traits #1562
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
e.g. for rustls-rustcrypto whilst validating OpenSSL interop
These traits could be not only useful for validation, testing and benchmark purposes and perhaps modelling TLS regardless the implementation where the underlying implementation can be switched behind.
There is already significant work trying to bridge between rustls / OpenSSL and making them universally switchable impls.
One common theme on TLS traits debate would probably be either lack of or embrace of async function coloring for I/O side.
Another debate probably is around how and how much API should protect mis-use and how to model the dangerous use of API
Think it should be sans-io and I/O layer is not in the scope for these traits - and should not involve OS/env decisions.
One thing rustls has adopted is typestate pattern in config builders to protect against misuse which could be helpful to model
Pondering along the lines of rand_core type traits like
RngCore
+CryptoRng
==CryptoRngCore
model for config:e.g.
TlsConfigCore
+ [TlsClientConfig
|TlsServerConfig
] ==Tls[Client|Server]ConfigCore
traitsThese "config core" traits could cast finalized to Tls implementation e.g. Client / Server specific probably that has re-negotiation / resumption etc. stuff but config is probably the initial low hanging fruit to address at shared trait level.
The text was updated successfully, but these errors were encountered: