[resending from a real computer since the security-sig auto(?)-moderator didn't like me top-posting from my phone :-)]
On Thu, Jan 19, 2017 at 9:29 AM, Cory Benfield <c...@lukasa.co.uk> wrote: > All, > > Thanks for your feedback on the draft PEP I proposed last week! There was a > lot of really enthusiastic and valuable feedback both on this mailing list > and on GitHub. > > I believe I’ve addressed a lot of the concerns that were brought up with the > PEP now, so I’d like to ask that interested parties take another look. Hi Cory, Great work! A few quick thoughts: - 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 attributes of this class just *be* bytestrings. I.e. what you have now but without the inheritance from enum. - what object types *do* you expect to be passed to wrap_buffers? I was assuming bytearrays, but the text at the bottom suggests file-likes? - a minor thing that I think is very important for usability is that there be some way to specify a name which library we're using with a single object. For example, curio has a high-level helper that abstracts over a lot of boilerplate in setting up a listening socket: await curio.tcp_server(host, port, client_connected_task, *, family=AF_INET, backlog=100, ssl=None, reuse_address=True) (Here ssl= is an SSLContext. Actually it's a curio.ssl.SSLContext -- see https://github.com/dabeaz/curio/blob/master/curio/ssl.py) Asyncio is similar: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.AbstractEventLoop.create_connection It isn't quite clear to me right now how this kind of API should look with your proposal. Obviously they can't just take a SSLConfiguration object, because there's no way to look at an SSLConfiguration object and figure out what backend is in use (even though in general a given SSLConfiguration is only usable with a specific backend, because backends provide the Cert type etc). They could take a ServerContext/ClientContext, I guess? But it would be nice if there were some way to say "give me the default configuration, using SChannel". Or to write a function that sets up an SSLConfiguration while being generic over backends, so like it takes the backend as an argument and then uses that backend's cert type etc. Maybe the solution is to require that each implementation provide a namespace where each of its concrete types are given standard names? So like I know schannel.ClientContext is the schannel implementation of the tlsabc.ClientContext interface? -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
