On 23 January 2014 22:41, "Martin v. Löwis" <martin at 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 | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4