Got it. Thanks again! On Friday, January 20, 2017, Cory Benfield <c...@lukasa.co.uk> wrote:
> > On 20 Jan 2017, at 16:30, Wes Turner <wes.tur...@gmail.com > <javascript:_e(%7B%7D,'cvml','wes.tur...@gmail.com');>> wrote: > > I think there's somewhat high likelihood that additional parameters will > be relevant to TLS Configuration in the future. > > > I think that we can upgrade “somewhat high likelihood” to “mathematical > certainty”. This again fits with my overall position, which is not to pitch > this as the completed solution but instead as a good starting point for > conservative evolution. > > As to the reduced set of cipher suites, all either do or will have IANA >> assigned names, and so can be managed as per the cipher enum. >> >> As to adding TLSConfiguration parameter fields, I think they are subject >> to the regular standard library update process. Generally speaking we >> should have a policy that adding fields should be a difficult thing to do >> unless there is substantial need for their addition, to avoid making the >> object almost impossible to manage. >> > > So the interface contract of the TLS configuration namedtuple is that > there are, minimally: > > - .attributes for each of tls._configuration_fields > - .update() > - __new__() # instantiation-time validation > > > Correct. Note that this isn’t an ABC like many of the other classes, but a > concrete implementation: it is not generally expected that TLS > implementations will want to add behaviours to this object, or to extend it > directly. > > IIUC, in order to validate a given configuration, the option is to: > > - subclass TLSConfiguration, define __new__(), and call super() > > > That shouldn’t be needed: just write a function that accepts one and look > at the values. > > So the normal standard library practice of duck-typing (and not explicitly > checking for TLSConfiguration in cls.__bases__) does or does not exclude > the use of an alternate configuration object which satisfies the interface > contract? > > > Does not exclude a duck-typed object. > > Is immutability a hard requirement of alternate/future implementations? > > > It’s hard to make immutability a hard requirement because there is no > enforcement mechanism for it. However, I think the appropriate caveat is > that if some future or alternate config object is mutable, and someone > mutates it after passing it to a Context, the outcome of that change is > undefined by this abstract API. > > Cory > >
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
