You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are maintaining a cacert.pem file because some users with old installed software in the operating system (openssl, curl...), especially in old distributions, had a lot of issues using HTTPS with Conan.
We could try to not generate it and (maybe as an opt-in) if the cacert.pem file exists in the cache, use it. That way users still can distribute it with conan config install and, in case of frequent errors, we could offer a fix with conan config install pointing to a zipped cacert.pem that could be upgraded anytime.
Feedback welcome!
The text was updated successfully, but these errors were encountered:
I suggest to don't have nothing about it in version 2, but have a "fallback" solution if users have some problem when migrate to conan 2. Version 2 on semantic version mean incompatible anyway.
Many companies (including the one I work for) use self-signed certificates for their self-hosted Artifactory servers.
So if you remove the default cacert.pem file that's ok as long as the mechanism is still available and we can ship our certificate chain with our conan config.
How it currently works in conan 1 is not optimal though. The best solution would be to use the systems ssl storage as described in #4353 or make use of the REQUESTS_CA_BUNDLE environment variable.
cacert.pem
file because some users with old installed software in the operating system (openssl, curl...), especially in old distributions, had a lot of issues using HTTPS with Conan.cacert.pem
file exists in the cache, use it. That way users still can distribute it withconan config install
and, in case of frequent errors, we could offer a fix withconan config install
pointing to a zippedcacert.pem
that could be upgraded anytime.Feedback welcome!
The text was updated successfully, but these errors were encountered: