> On 22 Jan 2017, at 17:01, Wes Turner <wes.tur...@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

_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Reply via email to