On 23 January 2014 22:41, "Martin v. Löwis" <mar...@v.loewis.de> wrote: > Am 23.01.14 07:45, schrieb Scott Dial: >> Anecdotally, I already know of a system at work that is using HTTPS >> purely for encryption, because the authentication is done in-band. So, a >> self-signed cert was wholly sufficient. The management tools use a >> RESTful interface over HTTPS for control, but you are telling me this >> will be broken by default now. What do I tell our developers (who often >> adopt the latest and greatest versions of things to play with)? > > If they play with the newest version before actually using it in > production, all is well. You can then tell them that they have > four options: > - not upgrade to the newest Python release (at least not until > they are willing to pursue any of the other alternatives) > - update the code to disable cert validation, or explicitly > add the self-signed cert as a trusted one programmatically. > - update the client system configuration, to add the self-signed > certificate as trusted (system-wide or per user). > - update the server, to use a cert signed by one of the > trusted CAs.
Or, depending on the exact transition plan, potentially set: PYTHONSSLDEFAULT=NOVERIFY (akin to the "no, really, don't randomise the hashes" option). That's the kind of question a PEP would be needed to thrash out, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
