[Security-sig] Unified TLS API for Python: Round 2

Nick Coghlan ncoghlan at gmail.com
Thu Jan 26 11:14:28 EST 2017

On 26 January 2017 at 16:22, Cory Benfield <cory at lukasa.co.uk> wrote:
> On 26 Jan 2017, at 14:23, Nick Coghlan <ncoghlan at gmail.com> wrote:
> In an ideal world, that could be handled just by having the ssl module
> import the new tls module and alias the exceptions accordingly.
> Talking to Christian about it, things might be a little messier in
> practice due to the way the _ssl/ssl C/Python split works, but there
> shouldn't be any insurmountable barriers to going down the exception
> aliasing path in 3.7+.
> I’d be ok with going down the aliasing route. Is this a concern worth noting
> in the PEP, do you think?

I think so, as the aliasing means that:

- new code can just catch the tls exceptions and automatically catch
the old ssl exceptions as well
- old code that just catches the old exceptions will also catch the
new exceptions, so helper library authors don't need to worry about
catching the new exceptions and re-raising them as the old ones

I don't think you need to explain the technical details of how the
aliasing would work though - that really is an implementation detail
(although you may want to provide a reference to Christian's email
that spells it out in full).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Security-SIG mailing list