+1 for start simple and iterate; but expecting a config object is not easy to add later. class SSLConfig(dict): def validate(self): """check types and (implementation-specific) ranges""" class _BaseContext(metaclass=ABCMeta): # def validate_config(self, cfg: Union[Dict, SSLConfig]) -> Boolean: """check types and (implementation-specific) ranges""" if not hasattr(cfg, 'validate'): cfg = SSLConfig(cfg) cfg.validate() self.cfg = cfg || return cfg def set_config(self, cfg: Dict): self.register_certificates(cfg[*]) self.set_ciphers(cfg[*]) self.set_inner_protocls(cfg[*]) if cfg.get(*) is not None: self.set_sni_callback(cfg[*]) Why a configuration object makes sense here: - Centralized config validation - Implementations may have unique parameters - Convenience: just pass the config params from {JSON, TOML, YAML, configobj, PasteDeploy, pyramid, ...} with sane validation On Thu, Jan 12, 2017 at 2:36 PM, Ian Cordasco <sigmavirus24@gmail.com> wrote:
-----Original Message----- From: Donald Stufft <donald@stufft.io> Reply: Donald Stufft <donald@stufft.io> Date: January 12, 2017 at 13:46:26 To: Cory Benfield <cory@lukasa.co.uk> Cc: security-sig@python.org <security-sig@python.org>, Christian Heimes <christian@cheimes.de> Subject: Re: [Security-sig] Unified TLS API for Python
On Jan 12, 2017, at 2:39 PM, Cory Benfield wrote:
I'm not even sure about the specific API we're using for SNI: I might
just want to restrict
it to emitting new certificates.
I am pro restricting the API, can always relax restrictions later.
Expanding APIs is always leagues easier than contracting them. Starting off with the minimum necessary API makes perfect sense. As needs are found that it cannot meet, then expanding it slowly and methodically will be easy and painless.
In other words, +1 on keeping it small to start and restricting the API. -- Ian Cordasco _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig