Larry Hastings added the comment: > My reading of this is that for OpenSSL Python defines a range of > compatible sonames at the time of the first release in a series (e.g. > 3.4.0), and then will never extend that in either direction for that > release series. Put another way: patches to extend the supported > OpenSSL versions are not acceptable in patch releases of Python. > > Is that reading accurate?
So, as RM, I don't exactly directly interact with our OpenSSL support. I don't decide on a version anywhere. I do test against it when I build and test, but I do my testing on Linux so I just wind up with whatever version of OpenSSL my OS shipped with. The decision about what version(s) to support on Windows and Mac falls to the Windows and Mac "platform experts", respectively Steve Dower and Ned Deily. When it's a platform-specific question regarding those two platforms, I defer to them. With all that said, my understanding is that the OpenSSL devs aren't very strict about what changes they make in minor releases (say, 1.0.2g -> 1.0.2h). I mean, sure, they might add bugs--it happens. But that's not what I'm talking about. IIUC they may introduce new features or even break APIs. So changing the OpenSSL version for an existing release doesn't seem like a very good idea, unless it's necessary to fix awful security holes. I wouldn't want to upgrade to a new OpenSSL point release just on basic "gee it's nice to stay current on software" general principles. As for this modifying the list of acceptable ciphers thing--at this point I'm fine with it, even for 3.4. I hope that clarified it for you. Sadly that's all the clarity I've got on hand. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27850> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
