python
starttls
Glyph and Antoine really want a API to upgrade an existing Transport/Protocol
pair to SSL/TLS, without having to create a new protocol.
Original issue reported on code.google.com by [email protected] on 24 Oct 2013 at 11:47
What exactly should be done?
Should protocol to be informed about upgrading to TLS? That's requires new
callback method in protocol contract.
Nikolay Kim and I have alternative proposal: add .detach() method to stream
transports for destroying transport without closing underlying socket.
There is my thoughts.
The method should return Future.
Proposed behavior is:
1. call event_loop.remove_reader(fd) and set some internal flag to don't close
the socket.
2. after sending transport's write buffer (if any) to the socket transport
removes own writer and sets Future result to None without closing the socket.
3. If sending write buffer produces error the exception will be passed to both
._force_close(exc) and future.set_exception(exc) in that order. Socket will be
closed.
4. Otherwise protocol receives .eof_received() notification, socket is not
closed. Transport calls protocol.detached() method instead to notify for
detachment. protocol.connection_lost is not called. .detached() method is
optional, if protocols doesn't implement it the base Protocol class doesn't
nothing.
5. After waiting for future (e.g. by `yield from transport.detach()`) client
code will receive raw socket instance:
rawsocket = yield from transport.detach()
The client is free to pass the same protocol instance to upcoming
loop.create_connection() call or make new protocol.
For former client will get .connection_made again.
The benefit of proposal: we also support migration to SSL/TLS for unix sockets,
pipes etc.
Developer can whatever he wants, even switch back to blocking mode and some
other staff.
Original comment by [email protected] on 16 Jun 2014 at 7:36
.detach() transport's method should to return the future with rawsocket for
success or exception if write buffer cannot be sent.
Original comment by [email protected] on 16 Jun 2014 at 7:51
It will become possible to implement STARTTLS when SSL was be rewritten by this
change:
http://bugs.python.org/issue22560
Original comment by [email protected] on 8 Jan 2015 at 11:23
Discussion about STARTTLS in a thread on the Tulip mailing list, when the PEP
was written:
https://groups.google.com/forum/#!msg/python-tulip/kEYYkq-TNnw/ueouVU3CvOMJ
Original comment by [email protected] on 13 Jan 2015 at 8:49
The new SSL implementation has been merged, it can be used on Python 3.5 (and
newer).
Original comment by [email protected] on 14 Jan 2015 at 12:51
There's now a CPython repo issue open for this (http://bugs.python.org/issue23749) and we have a possible volunteer.
