Be able to disable the certificate verification in the curl library

[T00mm]

Problem

While spinning up development images that don't have our enterprise CA included we get the following error on any cargo command that needs to contact the crates-io registry

Caused by:
    download of config.json failed
Caused by:
    [60] SSL peer certificate or SSH remote key was not OK (SSL certificate problem: unable to get local issuer certificate)

Normally you can bypass this by adding insecure to the cURL config file or by setting an environmental variable but the Easy library of cURL limits the environmental variables to a very limited set which SSL_VERIFY_PEER is not one of.

Would it be possible to be able to set the ssl_verify_peer option as well through the Cargo.toml config?

Proposed Solution

1. An option in the config with verify_peer set to true as default

pub struct CargoHttpConfig {
...
    pub no_verify_peer: Option<bool>,
...
}

2. Add code the the handle

pub fn configure_http_handle(config: &Config, handle: &mut Easy) -> CargoResult<HttpTimeout> {
...
    if let Some(no_verify_peer) = http.no_verify_peer {
        handle.ssl_verify_peer(!no_verify_peer)?;
    }
...

Notes

No response

[weihanglo]

Understand the situation. Instead of adding options one by one, is it possible to add an http.insecure option to mimic what curl --insecure is doing?

There is also a --proxy-insecure we might want to copy.

[weihanglo]

Hi. The cargo team has discussed this today. The team is curious to know the situation of needing such an escape hatch. An image that didn't include enterprise CA doesn't sound normal, and many other software would also stop working with the same situation. Could you say more about why you can't configure your own certificates, given that having a self-signed certificate is generally a safer way to fix the issue.

[T00mm]

I feel the current set-up limits you too much with these constraints. If the user is aware of the risks, my believe is that (s)he should be allowed to decide how the security should be enforced.

With GIT you can change it by editting the (git) config so I was expecting that for cURL it would be the same.

The issue came from when I wanted to show some co-workers a quick demo but could not even get past this error. That we then spend a good hour or two with figuring out which certificate should be imported, which format we needed to convert it to, which specific folder and CA-update command that flavour of Linux needed...

We were spending more time with getting the certificate on an image and importing it then the whole demo would have taken.

[ashemedai]

Ran into this myself today.

Typical use case:

• corporate security of network introduces a security product that does MitM
• you need to build test container images before you push them to your repository in your dev team
• cannot test cargo builds easily due to the certificate verification failing due to the, expected, MitM

You do not want to add the security product's certificate to the image since it will get deployed in environments, e.g. cloud, that are not your corporate network.

So yes, an image that does not have the enterprise CA is quite a normal thing.