killercup / killercup/cargo-edit
Feature request: Add support for cargo proxy configuration to ```cargo upgrade```
- Dominant language
- Rust
- Stars
- 3.5k
- Forks
- 166
- PR merge metrics
- No merged PRs in 30d
Description
To protect against the big rise in dependency confusion and compromised packages, we have implemented an internal 'cargo proxy' to be able to add policies to reduce exposure.
Cargo commands used for communicating with crates.io allows you to provide proxy server configuration in the .cargo/config.toml file:
```sh
cat /Users/MyUser/.cargo/config.toml
[http]
proxy = "socks5h://192.168.1.1:6789"
[https]
proxy = "socks5h://192.168.1.1:6789"
```
Unfortunately, ```cargo upgrade``` doesn't respect the .cargo/config.toml configuration, neither does it seem to pick up on environment variables ```HTTP_PROXY/HTTPS_PROXY``` for communication.
Here's the output:
```sh
cargo upgrade --verbose
Checking virtual workspace's dependencies
Error: error sending request for url (https://index.crates.io/an/yh/anyhow)
Caused by:
0: client error (Connect)
1: Socket is not connected (os error 57)
```
Would it be possible to add proxy support to cargo-edit commands where applicable? In my opinion the best way would be through cargo's generic configuration, but environment variables would also be an acceptable workaround.
Contributor guide
Research direction
Start by reproducing the cargo upgrade failure with the shown .cargo/config.toml proxy settings and HTTP_PROXY/HTTPS_PROXY environment variables. Trace how cargo-edit commands communicate with crates.io and compare that behavior with Cargo's configuration handling. Done means applicable cargo-edit commands use the configured proxy and the existing failing request succeeds through it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli, networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 50/100