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

[Cory Benfield]

> On 22 Jan 2017, at 17:01, Wes Turner <wes.turner at gmail.com> wrote:
> 
> - OpenSSL 1.1.0 supports DANE 
> - GnuTLS supports DANE
> - AFAIU, neither SChannel nor Secure Transport yet support DANE
> 
> So, in order to support e.g. DANE, where would the additional backend-specific configuration occur?

This would be up to the individual specific backends. They are allowed to extend the API provided here in whatever manner they see fit.

> A frozen ordered dict would be preferable because:
> 
> - Inevitable eventuality of new/additional config parameters
> - Consistency and readability of API access with [], .__getitem__(), .get()
> - https://www.python.org/dev/peps/pep-0416/#rejection-notice <https://www.python.org/dev/peps/pep-0416/#rejection-notice> ... 
> - https://docs.python.org/3.5/library/types.html#types.MappingProxyType <https://docs.python.org/3.5/library/types.html#types.MappingProxyType>
> 
> NamedTuple is preferable because:
> 
> - Immutability
> - Speed
> - RAM

So immutable types are key, and a truly-frozen ordered dict would be fine from that perspective.

However, the key reason I want to use a namedtuple instead of a dict is to discourage ad-hoc extension of the configuration type (with the side benefit of reducing the risk of typo-based configuration and implementation errors. Essentially, the dictionary approach encourages adding ad-hoc keys into the configuration, which *reduces* auditability and encourages the proliferation of essentially implementation-specific keys.

> If defined, backed specific configuration settings could take precedence over platform-neutral defaults.

So, that’s definitionally true. What’s very hard is coming up with a general way to express those backend-specific configuration settings, which is why I’m not really trying. In fact, it would probably be possible to argue that doing that is impossible.

Cory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170122/99763d65/attachment.html>