This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rkuska
Recipients alex, barry, bkabrda, doko, dstufft, janssen, lemburg, ncoghlan, pitrou, r.david.murray, rkuska, vstinner
Date 2015-04-07.09:09:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1428397750.69.0.744965299295.issue23857@psf.upfronthosting.co.za>
In-reply-to
Content
>Le 06/04/2015 13:29, Nick Coghlan a écrit :
>> 
>> So while this isn't a feature upstream itself needs, it's one
potentially needed by multiple *downstreams*, so in my view it makes
sense for us to work with upstream to come up with the "one obvious way"
for redistributors to handle the problem (now that we know that my
initial attempt at providing such a way doesn't work in practice).
>
>So would it be possible for the actual implementation to be done outside
of CPython? (in a dedicated fork, for example)

Yes it would and most likely will be, but as Nick pointed out, it is important to come up with the "one obvious way".


I understand why my patch is not acceptable for the upstream, it was my first shot (yet suitable for us) to start a discussion about cert verification. 

From the proposed solutions mentioned I favour the ENV variable which would address also Donald concerns, using ENV variable per application to enable/disable cert verification instead of global enable/disable, (yet it could be also `export`ed for global settings), are there any real disadvantages of using this method?
History
Date User Action Args
2015-04-07 09:09:10rkuskasetrecipients: + rkuska, lemburg, barry, doko, ncoghlan, janssen, pitrou, vstinner, alex, r.david.murray, bkabrda, dstufft
2015-04-07 09:09:10rkuskasetmessageid: <1428397750.69.0.744965299295.issue23857@psf.upfronthosting.co.za>
2015-04-07 09:09:10rkuskalinkissue23857 messages
2015-04-07 09:09:10rkuskacreate