[issue29470] ssl: SNI callbacks should not modify context objects

[David Ford (FirefighterBlu3)]

David Ford (FirefighterBlu3) added the comment:

@Christian, that was years ago and there were few examples available of people that had tried to make an SNI capable server. in several cases, people were monkey patching to make a callback. .set_servername_callback() didn't formally show up in ssl mod until 3.4.

i disagree that the documentation is very clear about this. there's one direct reference to usage which is worded as "A typical use of this callback is to...". that doesn't imply 'very clear' :}

i cannot recall anything anywhere that says one must not modify the context after it is used. 18.2.3 implies that a context is a long lived object, longer lived than a socket. it's clear that several people including myself, have mistakenly tried modifying the context after it was built. until now, it worked, probably purely by coincidence.

as a matter of fact, i used to change more than just the key loaded. i changed the ciphers, options, and verify_flags when i knew the incoming IP was incapable of supporting modern ciphers and options. i also modified the verify paths to support a messed up corporate environment.

i suggest the 18.2.3 documentation be modified to be clear about:
a) if, when, and how a context can be modified after creation
b) an SNI example that changes contexts and explicitly indicates (a)

i don't see any value to not being clear about it, and it's disingenuous to leave nooses hiding in shadows for devs to hang themselves with :-]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29470>
_______________________________________