I think this is a very common issue among those who want to use Cargo with Windows at work; I have seen multiple GitHub issues and forum posts related to it, but none of the answers solved my problems.
Whenever I try to build some code pointing to a crates.io crate, I get the following error:
Downloading <package>
error: unable to get packages from source
Caused by:
failed to download package <package> from <package address>
Caused by:
SSL connect error
What can I do to fix this? I know that Cargo can use the settings at .cargo/config and that the proxy details can be included there, but it doesn't work for me, with or without specifying the path for the certificate (I used the one distributed with curl), like below:
[http]
proxy = "http://user:password#proxy-address.xyz:port"
cainfo = "cert.pem"
[https]
proxy = "https://user:password#proxy-address.xyz:port"
cainfo = "cert.pem"
The proxy specified in the config file works for any other purpose.
I'm using Windows 7 64bit, Rust 1.11 GNU and Cargo bundled with it. How can I get this working? Currently I have to resort to downloading crate sources manually from their repositories and specifying paths = [...] for each of them in the Cargo config file.
I had the same problem, and I solved simply setting environment variables http_proxy and https_proxy with http(s)://user:password#proxy-address.xyz:port.
The only annoiyng part is that, when you need to unset the proxy (e.g. when you are smart-working from another network without using company's VPN) you have to unset / delete those variables.
It appears that this is no longer an issue as of cargo 0.13 bundled with Rust 1.13 stable - I no longer need to manually download packages and put them in paths in cargo's config file.
Related
Problem: I want to install a collection via ansible-galaxy, but one needs a proxy and the other one does not
galaxy.html of the needed collection:
dependencies:
community.docker: 2.4.0
git+https://gitlab.test.org/collections/test: master
In this example, community.docker needs a proxy to be installed, the other one fails if a proxy is set.
Is there a possibility to unset the proxy or set the proxy for a dependency in the galaxy.yml file?
Setting the no_proxy environment variable on the controller is a fine solution for this problem.
export no_proxy=gitlab.test.org
It can get rather aggregious to do this though if you have similar names for your gitlab instances, but worked for me.
Desired behavior
I would like to use CYPRESS_DOWNLOAD_MIRROR pointing toward my artifactory configuration for Cypress and just be able to do npm install and download library AND binary of Cypress
Current behavior
When setting Cypress in artifactory, and downloading it with CYPRESS_DOWNLOAD_MIRROR set toward this tool, the download script find binary files as X.Y.Z and not cypress.zip and fail. Apparently I can't rename binaries in artifactory. It seems to have made it available in a name X.Y.Z instead of cypress.zip
My artifactory admin tell me to do this command before but I can't since it's a post action of Cypress
curl –v « https://artifactory.mycompany.fr/artifactory/remote-download.cypress-generic/desktop/6.8.0?platform=win32&arch=x64 » > cypress.zip
Workaround
For now, I'm using CYPRESS_INSTALL_BINARY to point to a manually uploaded binary in artifactory but it's a pain because I have to separate Linux binary (for CI) and Windows binary (for dev) and if my package is configured with "cypress": "^6.2.1" the npm library will go to 6.2.1 and my binary will stuck to 6.2.0 for example...
Debug logs
Installing Cypress (version: 6.8.0)
× Downloading Cypress
→ Cypress Version: 6.8.0
Unzipping Cypress
Finishing Installation
The Cypress App could not be downloaded.
Does your workplace require a proxy to be used to access the Internet? If so, you must configure the HTTP_PROXY environment variable before downloading
Cypress. Read more: https://on.cypress.io/proxy-configuration
Otherwise, please check network connectivity and try again:
URL: https://artifactory.mycompany.fr/artifactory/remote-download.cypress.io/desktop/6.8.0?platform=win32&arch=x64
Error: self signed certificate in certificate chain
Download method
npm
Operating System
Linux
Windows
Other
I'm behind a proxy
I don't really know if it's an artifactory or a Cypress matter but I need help ^^
In addition to accepted answer, it is possible to replace pre-defined 'Query Params' with enabling 'Propagate Query Params'. If set, the query params passed with the request to Artifactory, will be passed on to the remote repo.
Please note, according to JFrog docs, this setting is only available for Generic type repositories.
I was able to make it work on Windows using the following:
I created a generic remote repository, making sure it is pointing to https://download.cypress.io, and under the advanced tab, added the query params: platform=win32&arch=x64 (notice there is a dedicated field for it).
The above is required in order to cache the correct binary based on the OS and arch (you might require a different remote repository with different query params).
I found it on Cypress doc that these query params control the binary type which will be downloaded (so we need to make sure it fits the client os and arch).
In the .npmrc I simply provided the following:
CYPRESS_DOWNLOAD_MIRROR=https://user:myverystrongpassword#myartifactory/artifactory/generic-cypress-windows
I've used this command (on MacOS) to directly pass path to downloaded Cypress.zip file
CYPRESS_INSTALL_BINARY=~/Downloads/cypress.zip yarn add cypress --D
We are running a local Artifactory Pro installation and have rubygems.org configured as a Remote Repository.
When running bundle install in a CI Job, the local Artifactory Instance does return a 404 File not found when querying for the /versions file. When doing a manual lookup in the Remote (&Cache) Repo, the file >is present<.
The path we pass to bundle install is provided by the Set me up Wizard and looks like this:
https://$rtf-instance.com/artifactory/api/gems/gems-remote/versions
This was mentioned in an issue here: https://www.jfrog.com/jira/browse/RTFACT-16005
and should have been fixed, but it is still not working in our installation.
Can't find any mention of RTFACT-16005 or the related RTFACT-19012 in the Release Notes.
Repo is setup with default values, no additional config done.
Are we missing something?
Environment:
debian 10 (buster)
nginx 1.14.2
artifactory-pro 7.15.4 / 7.15.3
To enable the gems compact index support you need to add the following system property (under $JFROG_HOME/var/etc/artifactory/artifactory.system.properties):
artifactory.gems.compact.index.enabled=true
You will need to restart Artifactory afterward.
This can be found in JFrog Wiki, here: https://www.jfrog.com/confluence/display/JFROG/RubyGems+Repositories#RubyGemsRepositories-RetrievingLatestRubyGemsPackageCompatiblewithYourRubyVersions
I am trying to work on a Go open source project, on a corporate device. Attempts to address the dependencies via dep ensure command always return 407 PROXY AUTH required. I do have http_proxy and https_proxy environment variable set with values in the format http://user:pasword#proxyname:proxyport. I have also attempted to set the git configs http.proxy. But I do get the same error. What am I missing?
Thanks
This is owing to Git client configuration issues and mismatch between git binary and gnutls. I have had to recompile git binary using openssl, to get this to work.
I believe my work proxy is preventing me from being able to add themes and packages to Atom. From the preferences menu, I get:
Fetching featured packages and themes failed. Hide output…
tunneling socket could not be established, cause=140499728967552:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:766:
Is it possible to make it use my $https_proxy variable? Is there some way to configure it to not use https?
You can configure your proxy settings in ~/.atom/.apmrc (or Atom\resources\app\apm\node_modules\atom-package-manager\.apmrc in Windows). Per the apm README:
If you are using a proxy you can configure apm to use it by setting the https-proxy config in your ~/.atom/.apmrc file like so:
https-proxy = https://9.0.2.1:0
It seems that as of Atom 1.0, there are some components that respect the http-proxy and https-proxy variables, and others that don't. For example, the initial check for the version of Atom works, but the check for packages doesn't seem to respect the http-proxy or https-proxy settings.
I was able to get Atom working with Fiddler as my proxy (on 127.0.0.1:8888) by running the following commands (on Windows):
apm config set proxy http://127.0.0.1:8888
apm config set strict-ssl false
I did not need to set http-proxy or https-proxy. I don't know if these settings have been deprecated or not, but they don't seem to work reliably in 1.0. The setting proxy works (and upgrades itself to TLS 1.2 automatically).
The entirety of my %USERPROFILE%\.atom\.apmrc file is:
strict-ssl=false
proxy=http://127.0.0.1:8888/
I was getting this error on Windows 7 fro Atom 1.0, when trying to look up packages.
In my case the issue was resolved by setting https-proxy variable to use http protocole instead of https. so both of the following parameters have exact same value.
here are the values from ~.atom.apmrc file
proxy=http://[host]:[port]/
https-proxy=http://[host]:[port]/
the answer by #NYCdotNet below that suggested to use
strict-ssl=false
didn't work as i was able to lookup some packages but installation failed with timeout error from GIT.
Atom will use your shell's proxy variables (like $https_proxy) if you start Atom from a shell that has these variables set. You need to have the Atom command line tools installed for that to work.
From a shell, you can simply type atom to open the editor for the current directory. It will use all environment variables from this shell, including the proxy variables.
I find this a lot easier than setting the variables in the config file.
I edited the ~/.atom/.apmrc file to set my proxy as mentioned by #AlexMooney, but still got errors.
The solution was to write
proxy = http://host:port
strict-ssl = false
in that ~/.atom/.apmrc file.
For Windows you can easily configure the https-proxy via command line:
amd config set https-proxy https://9.0.2.1:0
It should be stored under C:\Users\...\.apm in file .apmrc
See userconfig with command
amd config list
To config Proxy for Atom to install new pakage, just open CMD and run these commands:
apm config set strict-ssl false
apm config set proxy your_proxy
apm config set your_proxy
I am working behind a proxy server and spent about half a day on this issue, setting https_proxy as well as http_proxy didn't make a difference.
What did it for me was setting the proxy from the cmd line like so:
apm config set proxy http://myproxyaddress:port
I still can't install packages through Atom's gui, but doing it through the cmd line works fine. That I'll take.
I later realised I could've switched to the wifi and got it to work immediately...