[Python-Dev] Backwards compatibility after certificate autovalidation (original) (raw)

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

More information about the Python-Dev mailing list