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
It should be easy and ergonomic to use TLS with trio. This needs to be in the core.
My general idea is that trio.socket only exposes raw sockets, not fake-sockets-that-have-ssl-wrapped-around-them, and then we have a Stream adaptor that applies TLS. Initially using ssl.SSLObject and the BIO interfaces, but we should also keep a close eye on the plans for a new set of TLS APIs in the 3.7 time-frame (unfortunately now is kind of the worst time to be defining a TLS API!): Lukasa/peps#1
Anyway, I like this general design, but there are questions about how to make it ergonomic. Getting a socket + TLS is a pretty fundamental thing; we don't want it to feel cumbersome. And you might want to do things like call getsockopt or getpeername on your socket, which is tricky if you just called something like create_connection that handed you back a wrapped stream that doesn't have those methods! (Or worse, might hand back either a stream or a socket depending on the arguments you pass.) OTOH it would be nice if we can also make it pleasant to work with more complicated things like SNI callbacks etc. -- in jongleur I found curio's helper stuff pretty useless and immediately moved to separate socket and wrapped-socket objects anyway.
The thing where both for clients both the socket connect and the TLS handshake need to know the remote hostname is also a challenge for layering.
It should be easy and ergonomic to use TLS with trio. This needs to be in the core.
My general idea is that
trio.socket
only exposes raw sockets, not fake-sockets-that-have-ssl-wrapped-around-them, and then we have aStream
adaptor that applies TLS. Initially usingssl.SSLObject
and the BIO interfaces, but we should also keep a close eye on the plans for a new set of TLS APIs in the 3.7 time-frame (unfortunately now is kind of the worst time to be defining a TLS API!): Lukasa/peps#1Anyway, I like this general design, but there are questions about how to make it ergonomic. Getting a socket + TLS is a pretty fundamental thing; we don't want it to feel cumbersome. And you might want to do things like call
getsockopt
orgetpeername
on your socket, which is tricky if you just called something likecreate_connection
that handed you back a wrapped stream that doesn't have those methods! (Or worse, might hand back either a stream or a socket depending on the arguments you pass.) OTOH it would be nice if we can also make it pleasant to work with more complicated things like SNI callbacks etc. -- in jongleur I found curio's helper stuff pretty useless and immediately moved to separate socket and wrapped-socket objects anyway.The thing where both for clients both the socket connect and the TLS handshake need to know the remote hostname is also a challenge for layering.
#8 is closely related.
The text was updated successfully, but these errors were encountered: