On 13 January 2017 at 23:56, Cory Benfield <c...@lukasa.co.uk> wrote: > While we’re here, I should point out that this does not replace the abstract > contexts entirely, because we still need the wrap_* methods. These would now > just be fed a Configuration object (I’m more comfortable with the name > Configuration than Policy for this usage) in their constructor, and then > could use the wrap_* methods as needed.
Having a relatively passive configuration object sounds OK to me, and I agree it's distinct from a Policy object (which would store constraints on what an acceptable configuration looks like, rather than a specific configuration). > How does that idea sound to the rest of the list? It would definitely address my concern about making it easy for people to re-use the standard library's default TLS configuration settings, and it would also make it easier to have different defaults for different purposes. So the essential stack would look like: TLSConfig[uration?]: implementation independent, settings only TLSClientContext: ABC to combine settings with a specific TLS implementation TLSServerContext: ABC to combine settings with a specific TLS implementation TLSSocket: ABC to combine a context with a network socket TLSBuffer: ABC to combine a context with a pair of data buffers And then TLSPolicy would be a potential future implementation independent addition that could be used to constrain acceptable TLS configurations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
