[Python-Dev] Backwards compatibility after certificate autovalidation
Jim J. Jewett
jimjjewett at gmail.com
Tue Sep 9 02:40:43 CEST 2014
On Mon, Sep 8, 2014 at 3:44 PM, Cory Benfield <cory at lukasa.co.uk> wrote:
> On 8 September 2014 18:23, Jim J. Jewett <jimjjewett at gmail.com> wrote:
>> Summary: There needs to be a simple way to opt out at install time.
>> It would be far better to offer more fine-grained control, but leaving
>> that better solution to downstream is acceptable.
> Does this argument apply to a hypothetical 2.7 backport of this
> change, or does it apply to making the change in 3.5? (Or of course
I believe the argument applies even to 3.5, given that there was no
deprecation period. The concern is obviously stronger for maintenance
I am not saying that secure-by-default should wait until until 3.6; I
am saying that the "rush" requires even more attention than usual to
This actually argues *for* backporting the fix as at least opt-in, so
that 2.7/3.4 can serve as the "make your changes now, test them
without all the other new features" releases.
Nick's suggestion of a monkey-patching .pth file would be sufficient
backwards compatibility support, if the recipe were referenced from
the release notes (not just the python lib documentation).
Support for partial opt-in -- whether per-process, per call, per
address, etc -- would be nice, but it isn't required for backwards
I think that means an -X option for "noverifyhttps" should NOT be
added. It doesn't get users closer to the final solution; it just
adds the noise of a different workaround.
I assume that adding _unverified_urlopen or urlopen(context=...) do
provide incremental improvements compatible with the eventual full
opt-in. If so, adding them is probably reasonable, but I think the
PEP should explicitly list all such approved half-measures as a guard
against API feature creep.
More information about the Python-Dev