[Security-sig] Unified TLS API for Python: Round 2
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