> 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
