Option to disable SSL verify

[pawamoy]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

I'm trying to use poetry in a corporate environment. We have a private server and index for packages, and conda is setup to not verify SSL. Unfortunately, I didn't find a similar option or configuration for Poetry, so when I try to install a package with Poetry, it fails (SSLError).

I managed to get it to work by changing two lines in

https://github.com/sdispater/poetry/blob/51c7042160a74adf14038460468e5e5a72b0d965/poetry/repositories/legacy_repository.py#L415-L426

...to this:

     def _download(self, url, dest):  # type: (str, str) -> None
-        r = self._session.get(url, stream=True)
+        r = self._session.get(url, stream=True, verify=False)
         with open(dest, "wb") as f:
             for chunk in r.iter_content(chunk_size=1024):
                 if chunk:
                     f.write(chunk)

     def _get(self, endpoint):  # type: (str) -> Union[Page, None]
         url = self._url + endpoint
-        response = self._session.get(url)
+       response = self._session.get(url, verify=False)
         if response.status_code == 404:
             return

         return Page(url, response.content, response.headers)

Obviously we would use a value specified in the config.toml instead of a literal False.

[pawamoy]

I guess other modifications will be needed to be able to publish as well.

EDIT: I realize the code has changed now that 1.0 is live. My patch is not enough anymore. There's the _download method in pypi_repository.py to patch as well, but I still get the SSLError.

[pawamoy]

After talking with some colleagues, it seems that a better solution is to install the Certificate Authorities (CA) of your corporation on your system and configure your tools to use it, instead of disabling SSL verification (which is bad?).

There is a great answer on how to do this for Windows or Linux on this stackoverflow post.

I'm leaving this issue open since there were some upvotes, but I don't consider it myself a priority anymore.

[blunt1973]

really need this option too

[enicklas]

We have exactly the same issue. It would be great to have this option, similar to pip's trusted-host

[Celeborn2BeAlive]

I agree and I would argue that it is required to have such option to use poetry in a corporate environment with multiple private pipy indexes. You just don't want to have to deal with certificates when you know the repository is yours and can be trusted.
Having some option "trusted = true" under [[tool.poetry.source]] section could be great to specify this.

[piotr-kopacki]

Any progress on that?

[jhonatanTeixeira]

So, i have to stay using crappy pipenv because poetry doesn't have this super basic configuration

[Shackelford-Arden]

For what it's worth here, I've used this to succesfully bypass SSL validation without any code changes to Poetry:

https://stackoverflow.com/questions/48391750/disable-python-requests-ssl-validation-for-an-imported-module

TL;DR;

Set the CURL_CA_BUNDLE environment variable to an empty string.

[francoposa]

It looks like the poetry core PR is close to acceptance? python-poetry/poetry-core#80

This would be the last blocker for us to move over from pip.

We could set up a cert for the internal repository but this would be a much more direct path to adoption.

[absassi]

As I commented in python-poetry/poetry-core#80, I disagree with adding the option to pyproject.toml, because it is not consistent with the rest of TLS validation configuration that is already defined in the certificates.<repo> user config tree and because whether TLS validation should be disabled or not is a decision that might be different for each user. Also, in some cases, users might want to disable TLS validation without modifying the project code.

In my view, disabling the validation or defining the path to the CA file are basically the same configuration (so much that curl has only one single env var for both cases) and should be located in the same place. Either both in user configuration or both in the project, and I think in the user configuration makes more sense. I don't have anything against to allow defining them in both places (in case of defining the CA file in the project, it could be a relative path to allow one to commit it, although the security implications of this deserve further analysis, I think).