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

Cory Benfield cory at lukasa.co.uk
Tue Jan 24 04:06:44 EST 2017


> On 24 Jan 2017, at 01:59, Nathaniel Smith <njs at pobox.com> wrote:
> 
> I've just been used to using bytearrays everywhere for things like
> socket receive buffers. I find them much more convenient to work with
> than BytesIO b/c you can do things like pass them directly to
> send/recv/parsing functions, and they have nice properties like O(1)
> deletion from the front. It doesn't matter so much for this case where
> we're just shuffling bytes to and from a socket in a lump, but that's
> why I was assuming bytearrays without thinking about it :-). I guess
> h2's data_to_send and data_received don't involve any file-like
> objects either?

Yup, that’s very correct.

Ok, let’s update to include bytearray (really it should be any buffer type).

> Like, in the PEP as currently written, it goes to great efforts to
> make sure that generic code can be used to select cipher suites, but
> there's no way for a web server to load in certificate given a PEM
> filename, except via having a hard-coded table of all possible
> backends? The PEP says that each backend should somehow somewhere
> provide a concrete subclass of Certificate, but to find it you need to
> consult the backend-specific docs.
> 
> This is really a usability point that's mostly orthogonal to the
> semantics/design discussion and should be pretty straightforward to
> sort out, so it might make sense to defer worrying about it until the
> other stuff's more settled.

Yeah, this is a good catch. I had missed the problems around Certificate and TrustStore objects. Hrm.

Let me have a think about it and revise the PEP.

Cory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170124/379f2f1e/attachment-0001.html>


More information about the Security-SIG mailing list