Re: [Security-sig] Unified TLS API for Python: Draft 3

> On 10 Feb 2017, at 17:20, Wes Turner wrote: > > I learned about oscrypto: > > - oscrypto: "TLS (SSL) sockets, key generation, encryption, decryption, > signing, verification and KDFs using the OS crypto libraries. Does not > require a compiler, and relies on the OS

[Security-sig] Unified TLS API for Python 4: This Time It's Personal

to give this a slightly more cursory review than previously. As always, find the PEP below, or at this URL: https://github.com/Lukasa/peps/pull/1. Thanks, Cory — PEP: XXX Title: TLS Abstract Base Classes Version: $Revision$ Last-Modified: $Date$ Author: Cory Benfield <c...@lukasa.co

Re: [Security-sig] Unified TLS API for Python: Draft 3

> On 26 Jan 2017, at 21:17, Donald Stufft <don...@stufft.io> wrote: > > >> On Jan 26, 2017, at 4:18 AM, Cory Benfield <c...@lukasa.co.uk >> <mailto:c...@lukasa.co.uk>> wrote: >> >> For this reason I’m inclined to lean towards the more

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

> On 26 Jan 2017, at 14:23, Nick Coghlan 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

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

> On 21 Jan 2017, at 13:07, Nick Coghlan wrote: > > > I agree with Wes that the backwards compatibility guarantees around > adding new configuration fields should be clarified. > > I think it will suffice to say that "new fields are only appended, > existing fields are

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

> On 20 Jan 2017, at 23:00, Nathaniel Smith wrote: > > - given that for next protocol negotiation we have to accept arbitrary > bytestrings and the primary value of the NextProtocol class is to > protect against typos, I wonder if it would simplify things slightly > to make the

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

> On 20 Jan 2017, at 04:38, Wes Turner wrote: > > Thanks! TLSConfiguration looks much easier to review; and should make other > implementations easier. > > I read a great (illustrated) intro to TLS1.3 the other day: > >

Re: [Security-sig] Unified TLS API for Python

> On 13 Jan 2017, at 15:45, Nick Coghlan wrote: > > So the essential stack would look like: > > TLSConfig[uration?]: implementation independent, settings only > TLSClientContext: ABC to combine settings with a specific TLS implementation > TLSServerContext: ABC to

Re: [Security-sig] Unified TLS API for Python

> On 13 Jan 2017, at 09:07, Nathaniel Smith wrote: > > I was imagining something along the lines of > > ClientContext({...}).wrap_socket(...) > > where ClientContext.__init__ would do the validation. Or there are > various other ways to slot the pieces together, but in general

Re: [Security-sig] Unified TLS API for Python

> On 12 Jan 2017, at 05:36, Wes Turner wrote: > > So, with > > ``` > class TLSVersion(Enum): > MINIMUM_SUPPORTED > SSLv2 > SSLv3 > TLSv1 > TLSv1_1 > TLSv1_2 > TLSv1_3 > MAXIMUM_SUPPORTED > ``` > > What are

[Security-sig] Unified TLS API for Python

All, A recent change in the Fastly policy has led the distutils-sig to discover that there is a very real risk of many macOS installations of Python being entirely unable to access PyPI using pip, due to the fact that they are linked against the ancient system OpenSSL (see [1]). This problem

Re: [Security-sig] PEP 522: Allow BlockingIOError in security sensitive APIs on Linux

> On 22 Jun 2016, at 02:28, Nick Coghlan wrote: > > Hi folks, > > Over the weekend, Nathaniel Smith and I put together a proposal to > allow security sensitive APIs (os.urandom, random.SystemRandom and the > new secrets module) to throw BlockingIOError if the operating

Re: [Security-sig] RFC: PEP: Make os.urandom() blocking on Linux

> On 21 Jun 2016, at 23:57, Barry Warsaw wrote: > > At a minimum, I think a proper treatment of the alternative where os.urandom() > remains (on Linux at least) a thin wrapper around /dev/urandom. We would add > os.getrandom() as the low-level interface to the new C lib