<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=""><div class=""><br class=""></div><div class="">Sorry I was on my phone and didn’t get to fully reply to this.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 29, 2014, at 4:00 PM, M.-A. Lemburg <<a href="mailto:mal@egenix.com" class="">mal@egenix.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On 29.08.2014 21:47, Alex Gaynor wrote:<br class=""><blockquote type="cite" class="">Hi all,<br class=""><br class="">I've just submitted PEP 476, on enabling certificate validation by default for<br class="">HTTPS clients in Python. Please have a look and let me know what you think.<br class=""><br class="">PEP text follows.<br class=""></blockquote><br class="">Thanks for the PEP. I think this is generally a good idea,<br class="">but some important parts are missing from the PEP:<br class=""><br class=""> * transition plan:<br class=""><br class=""> I think starting with warnings in Python 3.5 and going<br class=""> for exceptions in 3.6 would make a good transition<br class=""><br class=""> Going straight for exceptions in 3.5 is not in line with<br class=""> our normal procedures for backwards incompatible changes.<br class=""></div></blockquote><div><br class=""></div><div><div>As far as a transition plan, I think that this is an important</div><div>enough thing to have an accelerated process. If we need</div><div>to provide a warning than let’s add it to the next 3.4 otherwise</div><div>it’s going to be 2.5+ years until we stop being unsafe by</div><div>default.</div><div><br class=""></div><div>Another problem with this is that I don’t think it’s actually</div><div>possible to do. Python itself isn’t validating the TLS certificates,</div><div>OpenSSL is doing that. To my knowledge OpenSSL doesn’t</div><div>have a way to say “please validate these certificates and if</div><div>they don’t validate go ahead and keep going and just let me</div><div>get a warning from it”. It’s a 3 way switch, no validation, validation</div><div>if a certificate is provided, and validation always.</div><div><br class=""></div><div>Now that’s strictly for the “verify the certificate chain” portion,</div><div>the hostname verification is done entirely on our end and we</div><div>could do something there… but I’m not sure it makes sense</div><div>to do so if we can’t do it for invalid certificates too.</div></div><br class=""><blockquote type="cite" class=""><div class=""><br class=""> * configuration:<br class=""><br class=""> It would be good to be able to switch this on or off<br class=""> without having to change the code, e.g. via a command<br class=""> line switch and environment variable; perhaps even<br class=""> controlling whether or not to raise an exception or<br class=""> warning.<br class=""></div></blockquote><div><br class=""></div><div>I’m on the fence about this, if someone provides a certificate</div><div>that we can validate against (which can be done without</div><div>touching the code) then the only thing that really can’t be</div><div>“fixed” without touching the code is if someone has a certificate</div><div>that is otherwise invalid (expired, not yet valid, wrong hostname,</div><div>etc). I’d say if I was voting on this particular thing I’d be -0, I’d</div><div>rather it didn’t exist but I wouldn’t cry too much if it did.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""> * choice of trusted certificate:<br class=""><br class=""> Instead of hard wiring using the system CA roots into<br class=""> Python it would be good to just make this default and<br class=""> permit the user to point Python to a different set of<br class=""> CA roots.<br class=""><br class=""> This would enable using self signed certs more easily.<br class=""> Since these are often used for tests, demos and education,<br class=""> I think it's important to allow having more control of<br class=""> the trusted certs.<br class=""></div></blockquote></div><div class=""><br class=""></div><div class="">Like my other email said, the Python API has everything needed</div><div class="">to easily specify your own CA roots and/or disable the validations.</div><div class="">The OpenSSL library also allows you to specify either a directory</div><div class="">or a file to change the root certificates without code changes. The</div><div class="">only real problems with the APIs are that the default is bad and</div><div class="">an unrelated thing where you can’t pass in an in memory certificate.</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>