Open alvieirajr opened 3 weeks ago
We have never supported this: https://requests.readthedocs.io/en/latest/search/?q=PYTHONHTTPSVERIFY
If packages that depend on the "request" package encapsulate the get() method in a way that does not give the user the option of determining whether or not to perform SSL validation, this makes it impossible to use the target endpoint if its certificate is expired. An example of this is the hugging face package. Because of this, I advocate the need to empower the user to be able to bypass the SSL check if the package they use does not provide this capability. As it stands, if the package used does not support bypassing validation and the certificate has expired, the project being built stops working until the external endpoint has its certificate updated (if it is updated). Because of this I understand that it would be a case of fixing.
If we agree that this need is valid, we then move on to the strategy of how this should be done in terms of implementation (since in terms of bureaucratic process I am still a noob in the python project, I only have 3 months in this universe). I advocate the use of the PYTHONHTTPSVERIFY environment variable because it has already been used within the Python ecosystem to signal, for example, that pip ignores SSL validation in previous versions.
I suggest using this environment variable for the sake of uniformity but I am open to suggestions.
In case of the ssl certificate of destination host has expired isn't possible to ignore the cert validation using env PYTHONHTTPSVERIFY=0.