You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 traits
These "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:
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: