[Python-Dev] Backwards compatibility after certificate autovalidation

[Jim J. Jewett]

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
> both.)

I believe the argument applies even to 3.5, given that there was no
deprecation period.  The concern is obviously stronger for maintenance
releases.

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
backwards compatibility.

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
compatibility.

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.

-jJ