Skip to content
This repository has been archived by the owner on Nov 23, 2017. It is now read-only.

starttls #79

Open
GoogleCodeExporter opened this issue Apr 10, 2015 · 6 comments
Open

starttls #79

GoogleCodeExporter opened this issue Apr 10, 2015 · 6 comments

Comments

@GoogleCodeExporter
Copy link

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 gvanrossum@gmail.com on 24 Oct 2013 at 11:47

@GoogleCodeExporter
Copy link
Author


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 andrew.s...@gmail.com on 16 Jun 2014 at 7:36

@GoogleCodeExporter
Copy link
Author

.detach() transport's method should to return the future with rawsocket for 
success or exception if write buffer cannot be sent.

Original comment by andrew.s...@gmail.com on 16 Jun 2014 at 7:51

@GoogleCodeExporter
Copy link
Author

It will become possible to implement STARTTLS when SSL was be rewritten by this 
change:
http://bugs.python.org/issue22560

Original comment by victor.s...@gmail.com on 8 Jan 2015 at 11:23

@GoogleCodeExporter
Copy link
Author

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 victor.s...@gmail.com on 13 Jan 2015 at 8:49

@GoogleCodeExporter
Copy link
Author

The new SSL implementation has been merged, it can be used on Python 3.5 (and 
newer).

Original comment by victor.s...@gmail.com on 14 Jan 2015 at 12:51

@gvanrossum
Copy link
Member

There's now a CPython repo issue open for this (http://bugs.python.org/issue23749) and we have a possible volunteer.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants