Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

constructor does not respect ssl_verify set manually or in condarc #851

Closed
2 tasks done
millsks opened this issue Sep 5, 2024 · 4 comments · Fixed by #860
Closed
2 tasks done

constructor does not respect ssl_verify set manually or in condarc #851

millsks opened this issue Sep 5, 2024 · 4 comments · Fixed by #860
Labels
type::bug describes erroneous operation, use severity::* to classify the type

Comments

@millsks
Copy link
Contributor

millsks commented Sep 5, 2024

Checklist

  • I added a descriptive title
  • I searched open reports and couldn't find a duplicate

What happened?

When executing constructor I receive SSL verify errors because of a self-signed certificate chain. This is normally taken care of with specifying the CA cert in ssl_verify or by using truststore to let it default to the CA cert stores on the server. No matter what I set the value of ssl_verify the value in the conda_context.ssl_verify referenced in fcp.py is always set to True. The only way I can get it to override is to use the environment variables CONDA_SSL_VERIFY=False or the REQUESTS_CA_BUNDLE with the path to a specific CA cert.

Is this by design or should the ssl_verify set in condarc be honored?

Additional Context

I am using micromamba 1.5.7-0 on Linux with the latest version of constructor. The issue is happening on a closed system that I do not have the ability to share screenshots.

@millsks millsks added the type::bug describes erroneous operation, use severity::* to classify the type label Sep 5, 2024
@jaimergp
Copy link
Contributor

jaimergp commented Sep 5, 2024

Yea, this block is problematic:

# We need to preserve the configuration for proxy servers and ssl, otherwise if constructor is
# running in a host that sits behind proxy (usually in a company / corporate environment) it
# will have this settings reset with the call to conda_replace_context_default
# See: https://github.com/conda/constructor/issues/304
proxy_servers = conda_context.proxy_servers
ssl_verify = conda_context.ssl_verify
with env_vars({
"CONDA_PKGS_DIRS": download_dir,
}, conda_replace_context_default):
# Restoring the state for both "proxy_servers" and "ssl_verify" to what was before
conda_context.proxy_servers = proxy_servers
conda_context.ssl_verify = ssl_verify

We'll need to improve the logic there a bit. Thanks for the report.

@jaimergp
Copy link
Contributor

@millsks, I opened #860. Can you give it a try locally and see if it fixes your issue?

@millsks
Copy link
Contributor Author

millsks commented Sep 19, 2024

Looks good from my local run with your ssl-verify branch. I put in print(f"conda_context.ssl_verify: {conda_context.ssl_verify}") after line 463 on constructor/fcp.py to verify in the output.

$ conda config --set ssl_verify true
$ grep ^ssl_verify ~/.condarc
ssl_verify: true
$ constructor Miniforge3 --dry-run --debug 2>&1|grep ssl_verify
conda_context.ssl_verify: True
^C
$ conda config --set ssl_verify false
$ grep ^ssl_verify ~/.condarc
ssl_verify: false
$ constructor Miniforge3 --dry-run --debug 2>&1|grep ssl_verify
conda_context.ssl_verify: False
^C
$ conda config --set ssl_verify truststore
$ grep ^ssl_verify ~/.condarc
ssl_verify: truststore
$ constructor Miniforge3 --dry-run --debug 2>&1|grep ssl_verify
conda_context.ssl_verify: truststore
^C

@millsks
Copy link
Contributor Author

millsks commented Sep 19, 2024

This is the version that is installed on my local system using your branch.

$ constructor --version
constructor 2.0.3.dev689+gbb1c92a
$ conda list|grep ^constructor
constructor               2.0.3.dev689+gbb1c92a          pypi_0    pypi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type::bug describes erroneous operation, use severity::* to classify the type
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants