Open garfieldthecat opened 1 year ago
In my work network there are 3 .crt certificate files that can be used.
I have changed the .condarc file so that
ssl_verify: c:\users\username\certificate_file.crt
conda works if I specify any of the 3 .crt files.
mamba does not work with any of the 3 files
The files are:
My interpretation is that there is nothing wrong with my network, my certificates work fine, my firewall/proxy is not blocking access to conda-forge and the issue is with mamba, which should replicate the syntax and functionality of conda but, in this specific instance, does not (conda works perfectly well).
Has anyone else tried to use mamba behind a corporate firewall/proxy and/or with .crt certificates? Surely I can't be the only one in this situation?
Can you try to get it to work with curl only? Like downloading the repodata file.
Can you try to get it to work with curl only? Like downloading the repodata file.
Forgive me if it's a banal question, but how exactly would I do that? Do you mean downloading the .json file locally and then adding some parameters to tell mamba to look up the json stored locally?
No just use curl to download the file for debugging. No way to use it in Mamba then. Just for testing purposes. If that works then it’s a problem with Mamba, otherwise it’s a problem with curl.
Thank you for the suggestion - very useful - we may finally be getting somewhere
I played around with the curl syntax; it works if I run
curl --proxy same_proxy_server_as_in_the_condarc_file.com https://conda.anaconda.org/conda-forge/noarch/repodata.json
If I run
curl https://conda.anaconda.org/conda-forge/noarch/repodata.json
curl --insecure https://conda.anaconda.org/conda-forge/noarch/repodata.json
curl --http1.0 https://conda.anaconda.org/conda-forge/noarch/repodata.json
I get a
curl: (28) Failed to connect to conda.anaconda.org port 443 after 4229 ms: Timed out
I get the same message if I set ssl_verify to False and if I set it to any of the 3 certificate files I mentioned above. Do you get the same error message, too?
It also works if I add the proxy to the environment variables, then run curl without a parameter for the proxy: set http_proxy=same_proxy_server.com set https_proxy=same_proxy_server.com curl https://conda.anaconda.org/conda-forge/noarch/repodata.json but it does not work if I run mamba install somepackage after setting environment variables for the proxy server as above!
The problem is not with curl but with mamba - curl with the right proxy settings works just fine
If we download the repodata.json manually, would it be possible to add it to the local cache? Would that make a difference? As in, that way mamba doesn't have to connect to the remote json anymore?
Interesting, what's the output of curl -V
?
Does Conda (as opposed to Mamba) respect the environment variables?
Curl reads the environment variables (for the proxy servers)
Conda was finding the proxy settings in the .condarc file. Whether it would have worked with the proxy set in the environment variables but not the .condarc I don't know.
Mamba is supposed to recognise the proxy settings in the .condarc file. Supposedly...
As for the output of curl -v (lower case v) - by the way, the powershell prompt did not show the output, only the ordinary prompt - it's this, except some details anonymised :
(base) c:\users\username>curl -v https://conda.anaconda.org/conda-forge/noarch/repodata.json
* Uses proxy env variable https_proxy == 'http://work_proxy_server.com:8080'
* Trying x.y.z:8080...
* Connected to work_proxy_server.com (x.y.z) port 8080 (#0)
* allocate connect buffer
* Establish HTTP proxy tunnel to conda.anaconda.org:443
> CONNECT conda.anaconda.org:443 HTTP/1.1
> Host: conda.anaconda.org:443
> User-Agent: curl/7.83.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection Established
< Proxy-Agent: Zscaler/6.2
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
> GET /conda-forge/noarch/repodata.json HTTP/1.1
> Host: conda.anaconda.org
> User-Agent: curl/7.83.1
> Accept: */*
>
* schannel: failed to decrypt data, need more data
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Tue, 04 Apr 2023 12:21:58 GMT
< Content-Type: application/json
< Content-Length: 84022577
< Connection: keep-alive
< CF-Ray: some_code
< Accept-Ranges: bytes
< Age: 9218
< Cache-Control: public, max-age=1200
< ETag: "some_code"
< Expires: Tue, 04 Apr 2023 12:41:58 GMT
< Last-Modified: Tue, 04 Apr 2023 09:47:35 GMT
< Vary: Accept-Encoding
< CF-Cache-Status: HIT
< x-amz-id-2: some_id
< x-amz-request-id: some_other_id
< x-amz-version-id: null
< Set-Cookie: __cf_bm=some_code; path=/; expires=Tue, 04-Apr-23 12:51:58 GMT; domain=.anaconda.org; HttpOnly; Secure; SameSite=None
< Server: cloudflare
<
{
"info": {
"subdir": "noarch"
},
"packages": {
"_current_repodata_hack_gcc_linux_64_75-0.0.1-0.tar.bz2": {
"build": "0",
"build_number": 0,
"depends": [
"gcc_linux-64 7.5.*"
],
"license": "LicenseRef-OTHER",
"md5": "6f29ba77e8b03b191c9d667f331bf2a0",
"name": "_current_repodata_hack_gcc_linux_64_75",
"noarch": "generic",
"sha256": "ecde63af23e0d49c0ece19ec539d873ea408a6f966d3126994c6d33ae1b9d3f7",
"size": 3357,
"subdir": "noarch",
"timestamp": 1599854591823,
"version": "0.0.1"
},
No I meant curl -V
:)
Note that curl
in PowerShell might actually be a different program shipped with Windows that's aliased to curl
, not the real curl.
Some observations:
curl
command line (7.88 vs 7.83)https://
but here it starts with http://
.condarc
you are not including the http://
As for https vs https in the proxy settings and in the .condarc : I have played around with a gazillion different combinations. They al work fine with conda, while none works with mamba.
Yes, if I set the proxy in the environment variable then curl works. I have no idea if mamba does not send the correct proxy settings to mamba, or if it does and the issue is elsewhere. I don't have a proxy without zscaler to test this hypothesys.
Have you tried contacting zscaler at all?
As for the output with the capital V:
(base) c:\users\username>curl -V https://conda.anaconda.org/conda-forge/noarch/repodata.json
curl 7.83.1 (Windows) libcurl/7.83.1 Schannel
Release-Date: 2022-05-13
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS HSTS IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI UnixSockets
One last request, can you try to upgrade curl to 7.88 and confirm that it still works?
To me it looks like a problem with Mamba and not with Zscaler because vanilla curl works.
You mean update the curl used by mamba? How do I do that? It's not even clear to me where the two curls, the one used in the command prompt and the one used by mamba, are.
If I search my C: drive for curl.exe
, I find only one, in C:\Program Files\Git\mingw64\bin
, and that's version 7.61.1
If I search for libcurl.dll
, I see a few:
SQL McAfee Office\ODBC\Salesforce drivers R Cisco spark
No the curl
command line program. Mamba uses libcurl
. Not sure where your curl
command line program is coming from.
But you can try with the mingw one as well!
I updated libcurl in the base environment to 7.88.1. Updating libcurl solved this issue https://github.com/mamba-org/mamba/issues/1856 for the user who raised it, but changed absolutely nothing for me.
I have learnt that curl is now part of Windows: https://curl.se/windows/microsoft.html
Since curl version 7.83.1 (the one that comes with Windows) does download the json (if I set the proxy in the environment variables) I downloaded version 7.83.1 from https://curl.se/windows/dl-7.83.1/ I ran that, and got:
H:\curl-7.83.1-win64-mingw\bin>curl https://conda.anaconda.org/conda-forge/noarch/repodata.json
curl: (60) SSL certificate problem: self-signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
So: the curl 7.83.1 which is part of Windows works, while the curl 7.83.1 one can download from the curl website does not! It seems the former recognises all the settings for proxy ssl certificates etc, while the latter does not.
What a headache!
I wonder if the Windows curl has some „hidden“ settings/certificate stores that the normal one doesn’t.
Having the exact same issue as OP reports. Using zscaler as well. Conda works, mamba doesn't.
Has anyone tried mamba from a proxy / firewall that is NOT zscaler? Is there an easy way to connect to a proxy from a home PC?
Yes that should just work
Sorry, what should just work? Is there some kind of free proxy service I can connect to from my home PC, just to test the connection?
There are some free proxy services, or you can try a VPN provider that allows to connect via HTTP proxy. If it works in your browser it should also work with Conda and Mamba (except Zscaler…)
Though ideally would be nice to have mamba
work with Zscaler and conda-forge
, or at least find a configuration setting that allows its use, given that conda
works, and that curl
provided by default in PowerShell also works.
Following-up, this is not specific to Windows. I am having the exact same problem on Ubuntu 22.04 (via WSL2), only affecting mamba, not conda.
@jeanmonet that's good to know because I assumed this is related to the Windows SSL stack. Can you try to reproduce the issue with some version of curl?
Please see below (successful) result using default curl
installed with Ubuntu 22.04:
$ curl https://conda.anaconda.org/conda-forge/noarch/repodata.json -o _temp_cf.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 83.6M 100 83.6M 0 0 34.0M 0 0:00:02 0:00:02 --:--:-- 34.0M
$ curl --version
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd
EDIT: mamba with conda-forge appears to work in WSL2/Ubuntu (don't know what happened or if it's temporary, started workig apparently after running the curl command above inside WSL). However still no-go on PowerShell (Windows).
It might be that the problem comes from Zscaler intermediate root CA certificate.
It can be found, in Windows, as such:
Conda (and default curl in PowerShell) probably make use of this certificate and that is why connections work fine (presumably).
Is there any way that mamba can do the same?
Troubleshooting docs
Search tried in issue tracker
yes, nothing found
Latest version of Mamba
Tried in Conda?
Not reproducible with Conda
Describe your issue
The issue
At home I am a happy user of Mambaforge on my Windows PC I installed the same on my work PC (also Windows) behind a corporate firewall, after uninstalling Anaconda, but mamba couldn't download any package. Odd, because the very same proxy settings worked with Anaconda. So I installed miniconda, installed mamba from conda-forge, ran
conda clean --all
, and tried again: with the very same .condarc file and proxy settings, conda works, mamba does not. See error message in the section below. it didn't make a difference, but I also installed conda-build.Please note, I installed only mamba and condabuild - all the other packages in my environment were installed by conda when I installed these two.
My interpretation
My guess is that, since conda works with the very same proxy settings and .condarc files, the proxy server is not blocking access to the conda-forge repository. So I guess it must be one of:
What I have found
There is a vaguely similar report, where a user fixed the issue by setting the proxy outside of .condarc : https://github.com/mamba-org/mamba/issues/151#issuecomment-1081449544
but that didn't work for me - I get the same error.
There are other reports about SSL issues https://github.com/mamba-org/mamba/issues/1106 but that's not the error I am getting.
my .condarc file
conda doesn't work with ssl_verify set to true. mamba doesn't work with either setting.
The error report
mamba info / micromamba info
Logs
environment.yml
~/.condarc