> On 22 Jan 2017, at 18:55, Wes Turner <wes.tur...@gmail.com> wrote: > > So then there are two ways to preserve the centralized configuration (with a > configuration object): > > 1. extra_config, a TLSConfiguration parameter pointing to e.g. a (mutable) > List or an OrderedDict of additional parameters > 2. create an additional configuration object for additional configuration > parameters
Immutable types that contain user-modifyable mutable types are not immutable. ;) They are immutable *references*. I’m shooting for actual immutability here, which is why most of the API surface that accepted lists has been changed to require tuples instead. That means only (2) could work. It may be that the sensible idea is to say that the _BaseContext constructor should take one config object and then a Mapping of implementation-specific-constant to implementation-specific-config. But I don’t know that we need to enshrine that in the API: concrete implementations that need to do this can simply accept those as extra arguments without violating the abstract API. > One use case is applications which don't/won't define any actual config code > for their app; they just want it to work everywhere (which may mean working > with each platform's native TLS library). There's then an external config to > be read into TLSConfiguration (and whatever else for backend-specific > configuration parameters) Sure, but how do you choose which implementation to use? For example, Python-on-macOS may find that there are backends available for SecureTransport, OpenSSL, and GnuTLS (say). There is no general correct answer to “what should I use here”: the answer is up to application developers. The best we could do is provide a hook that says “what does Python prefer”, and we may well have to do that eventually if we want to include stdlib support for other backends (so that httplib and friends can DTRT). However, we don’t need to put it into this API right now, and I don’t think there’s a good way to do it generically that doesn’t require someone, somewhere to make a choice. My argument is that whomever is choosing should also actually supply the Context as the method to indicate their choice. For example, Requests would have a function that attempts to import a whole bunch of TLS backends and selects the Context it would prefer to use on a given platform (allowing users to supply just TLSConfiguration if they’re that way inclined), while also allowing users to supply initialized Context objects if they want to. Cory _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
