> On 21 Jan 2017, at 13:07, Nick Coghlan <ncogh...@gmail.com> wrote: > > > I agree with Wes that the backwards compatibility guarantees around > adding new configuration fields should be clarified. > > I think it will suffice to say that "new fields are only appended, > existing fields are never removed, renamed, or reordered". That means > that: > > - tuple unpacking will be forward compatible as long as you use *args at the > end > - numeric lookup will be forward compatible
Good idea. > This intro section talks about a combined "Context" objection, but the > implementation has been split into ServerContext and ClientContext. > > That split could also use some explanation in the background section of the > PEP. Good idea, I’ll expand on that. >> Proposed Interface >> ^^^^^^^^^^^^^^^^^^ >> >> The proposed interface for the new module is influenced by the combined set >> of >> limitations of the above implementations. Specifically, as every >> implementation >> *except* OpenSSL requires that each individual cipher be provided, there is >> no >> option but to provide that lowest-common denominator approach. > > The second sentence here doesn't match the description of SChannel > cipher configuration, so I'm not clear on how the proposed interface > would map to an SChannel backend. Yeah, this is a point I’m struggling with internally. SChannel’s API is frustratingly limited. The way I see it there are two options: 1. Allow the possibility that SChannel may allow ciphers that others do not given the same cipher configuration. This is not a good solution, frankly, because the situation in which this will happen is predominantly that SChannel will allow modes or key/hash sizes that the other implementations would forbid, given the same cipher configuration. 2. Force all other implementations to be as bad as SChannel: that is, to make it impossible to restrict key sizes and cipher modes on all implementations because SChannel can’t. I don’t really like either of those choices. I *think* 2 is worse than 1, but I’m not sure about that. People with opinions should really weigh in on it. > This is the one part of the PEP that I think may need to discuss > transition strategies for libraries and frameworks that currently let > ssl module exceptions escape to their users: how do they do that in a > way that's transparent to API consumers that currently capture the ssl > module exceptions? The short answer is that users who currently capture the ssl module exceptions need to start catching these exceptions instead when they transition. Cory _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
