<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 2, 2014, at 7:47 PM, Glyph Lefkowitz <<a href="mailto:glyph@twistedmatrix.com" class="">glyph@twistedmatrix.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><div class="">On Sep 2, 2014, at 4:28 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><p dir="ltr" style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On 3 Sep 2014 09:08, "David Reid" <<a href="mailto:dreid@dreid.org" class="">dreid@dreid.org</a>> wrote:<br class="">><br class="">> Nick Coghlan <ncoghlan <at><span class="Apple-converted-space"> </span><a href="http://gmail.com/" class="">gmail.com</a>> writes:<br class="">><br class="">> > Creating *new* incompatibilities between Python 2 & Python 3 is a major point<br class="">> > of concern.<br class="">><br class="">> Clearly this change should be backported to Python2.</p><p dir="ltr" style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Proposing to break backwards compatibility in a maintenance release (...)</p></blockquote></div><div class="">As we keep saying, this is not a break in backwards compatibility, it's a bug fix.  Yes, systems might break, but that breakage <i class="">represents an increase in security</i> which may well be operationally important.  Not everyone with a "working" application has the relevant understanding an expertise to know that Python's HTTP client is exposing them to surveillance.  These applications <i class="">should</i> break. That is the very nature of the fix.  It is not a "compatibility break" that the system starts <i class="">correctly</i> rejecting invalid connections.</div><div class=""><br class=""></div><div class="">By way of analogy, here's another kind of breach in security: an arbitrary remote code execution vulnerability in XML-RPC.  I think we all agree that any 0day RCE vulnerabilities in Python really ought to be fixed and could be legitimately included without worrying about backwards compatibility breaks.  (At least... gosh, I hope so.)</div><div class=""><br class=""></div><div class="">Perhaps this arbitrary remote execution looks harmless; the use of an eval() instead of an int() someplace.  Perhaps someone discovered that they can do "3 + 4" in their XML-RPC and the server does the computation for them.  Great!  They start relying on this in their applications to use symbolic values in their requests instead of having explicit enumerations.  This can save you quite a bit of code!</div><div class=""><br class=""></div><div class="">When the RCE is fixed, this application will break, and <i class="">that's fine</i>.  In fact that's the whole point of issuing the fix, that people will no longer be able to make arbitrary computation requests of your server any more.  If that server's maintainer has the relevant context and actually wants the XML-RPC endpoint to enable arbitrary RCE, they can easily modify their application to start doing eval() on the data that they received, just as someone can easily modify their application to intentionally disable all connection security.  (Let's stop calling it "certificate verification" because that sounds like some kind of clerical detail: if you disable certificate verification, TLS connections are unauthenticated and unidentified and therefore insecure.)</div><div class=""><br class=""></div><div class="">For what it's worth, on the equivalent Twisted change, I originally had just these concerns, but my mind was changed when I considered what exactly the user-interface ramifications were for people typing that 's' for 'secure' in URLs.  I was convinced, and we made the change, and there have been no ill effects that I'm aware of as a result.  In fact, there has been a renewed interest in Twisted for HTTP client work, because we finally made security work more or less like it's supposed to, and the standard library is so broken.</div><div class=""><br class=""></div><div class="">I care about the health of the broader Python community, so I will passionately argue that this change should be made, but for me <i class="">personally</i> it's a lot easier to justify that everyone should use Twisted (at least since 14+) because transport security in the stdlib is such a wreck and even if it gets fixed it's going to have easy options to turn it off unilaterally so your application can never really be sure if it's getting transport security when it's requesting transport security.</div><div class=""><br class=""></div></div></div></blockquote><br class=""></div><div>I completely agree with everything Glyph has said in this post. (To the shock of everyone involved I’m sure!).</div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>
</div>
<br class=""></body></html>