[Security-sig] Unified TLS API for Python

[Nathaniel Smith]

On Jan 13, 2017 3:17 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

On 13 January 2017 at 19:33, Nathaniel Smith <njs at pobox.com> wrote:
> On Fri, Jan 13, 2017 at 1:09 AM, Cory Benfield <cory at lukasa.co.uk> wrote:
> I get what you're saying about a typed API -- basically in the current
> setup, the way _BaseContext is written as a bunch of Python methods
> means that the interpreter will automatically catch if someone tries
> to call set_cihpers, whereas in the dict version each implementation
> would have to catch this itself. But in practice this difference seems
> really minimal to me -- either way it's a runtime check

The difference isn't minimal at all from the perspective of:

- static type analysis
- runtime introspection
- IDEs (which use a mixture of both)
- documentation

Config dictionary based APIs have *major* problems in all those
respects, as they're ultimately just a bunch of opaque-to-the-compiler
keys and values.

Network security is a sufficiently hard problem that we want to make
it as easy as possible for developers to bring additional tools for
ensuring code correctness to bear :)

> and it's
> really difficult to write a loop like
>
>   for key, value in config.items():
>       do_some_quirky_cffi_thing_based_on_key()
>
> that doesn't implicitly validate the keys anyway. There's also the
> option of using e.g. JSON-Schema to write down a formal description of
> what goes in the dict -- this could actually be substantially stricter
> than what Python gets you, because you can actually statically enforce
> that validate_certificates is a bool. For whatever that's worth --
> probably not much.

I've generally found that it's easier to build a declarative API atop
a programmatic API than it is to tackle a problem the other way
around:

1. Even if the only public API is declarative, there's going to be a
programmatic API that implements the actual processing of the
declarative requests
2. Working with the programmatic API provides insight into which
features the declarative API should cover, and which it can skip
3. Programmatic APIs are often easier to test, since you can more
readily isolate the effects of the individual operations
4. A public programmatic API serves as a natural constraint and test
case for any subsequent declarative API


I totally buy these as advantages of a generic programmatic API over a
generic declarative API, but I'm not sure how much it applies given that in
this case the "programmatic" API we're talking about is literally *nothing*
but getters and setters. Spelling set_ciphers correctly is certainly
important and it's nice if your IDE can help, no doubt. But let's keep this
in perspective - I don't think this is the *hard* part of network security,
really :-). And I can't resist pointing out that in your other email sent
at the same time, you're musing about out how nice it would be if only
there were some way the stdlib could export its idea of a "default tls
configuration" as some sort of concrete object that arbitrary tls
implementations could ingest... which is *exactly* what the config-dict
approach provides :-).

I guess another possible point in the design space would be to split the
difference: instead of an abstract context class or a dict, define a
concrete context class that acts as a simple transparent container for
these settings, effectively layering the type safety etc over its __dict__.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170113/20fe4569/attachment-0001.html>