corporate proxy got in the way and cannot specify a certificate bundle using en vars like such as CARGO_HTTP_CAINFO, SSL_CERT_FILE & SSL_CERT_PATH

[NobodyXu]

I found out about cargo-binstall through this awesome introductory blog post about cargo-dist. I am admittedly late to the party. Unfortunately, when I went to try this out at work, the corporate proxy got in the way and I can't yet figure out how to specify a certificate bundle like I can with other apps. I already have the customary environment variables set properly such as CARGO_HTTP_CAINFO, SSL_CERT_FILE, and SSL_CERT_PATH. This is a bit frustrating but doesn't have to be the end. Excited to learn more.

Originally posted by @yonkeltron in #19 (comment)

[NobodyXu]

@yonkeltron It should be possible since we use reqwest for making http requests and it has ClientBuilder::add_root_certificate for adding a custom root certificate.

Not sure whether this will fix your issue since I do not have the experience of corporate proxy, but it does work for you, I am more than happy to add that feature.

[NobodyXu]

@passcod I'm not very familiar with corp proxy env, will using ClientBuilder::add_root_certificate to add root certificate help here?

[passcod]

Not familiar either. That sounds like it's intercepting TLS? Weird. Probably need to check out how cargo does it.

[yonkeltron]

Yes corporate proxies do tend to MITM and intercept TLS connections to be cracked at the network border. This would be an amazing feature to have and I would love to help test it out if I can contribute somehow. I am so grateful for the attention. Thanks, +Jonathan

…

On Fri, Feb 3, 2023, 8:13 PM Félix Saparelli ***@***.***> wrote: Not familiar either. That sounds like it's intercepting TLS? Weird. Probably need to check out how cargo does it. — Reply to this email directly, view it on GitHub <#759 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOQO2IEWFIIYGZLUPEOBDWVWUNFANCNFSM6AAAAAAUOMOYPY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[NobodyXu]

@yonkeltron If that is the case, then can you check if ClientBuilder::add_root_certificate solve the issue based on how your corp proxy works?

If the answer is yes, then I can open a PR to add this feature and let you test it out.

[NobodyXu]

Hmm, I will go ahead and create a PR so that you can test this.

[yonkeltron]

Hey I'm ready to give this a shot whenever you give me the go ahead. I'll happily provide all the feedback and experience info I can muster!

[NobodyXu]

Hey I'm ready to give this a shot whenever you give me the go ahead. I'll happily provide all the feedback and experience info I can muster!

The PR linked with this issue is already ready for review and it also has pre-built artifacts for you to try out.

[yonkeltron]

Ok, after a false start owing to an error on my part, it seems to be working fine now! I love this! Can't wait to tell others once it's out. Is there any other info I can provide?

[NobodyXu]

@yonkeltron Good to hear that this resolves this issue!

Since you are in corp env, is there anything else that we can make it easier to use binstall in that kinds of env or could potentially block usage of binstall?

[yonkeltron]

is there anything else that we can make it easier to use binstall in that kinds of env or could potentially block usage of binstall?

Right now, no. My biggest issues are a proxy and the cert it requires, both of which seem to work just fine right now. I think we're good to go but I'll keep my eyes open. Thanks so much for all of your help and support. It means a lot and your hard work really matters!

Thanks,
+Jonathan

[NobodyXu]

Thank you Jonathan!

We would probably make a release this weekend or next Monday along with other fixes for http conns.
There are quite some issues due to the auto discovery mechanism creating quite a lot requests in a short time that we are now trying to resolve by increasing the interval in rate limiting and add more wait and retry logic to binstalk-downloader.

[NobodyXu]

@yonkeltron #820 adds --root-certificates option and read from BINSTALL_HTTPS_ROOT_CERTS if the option is not specified.

I removed CARGO_HTTP_CAINFO, SSL_CERT_FILE and SSL_CERT_PATH since these env variables seem to be set in our CI somehow and it might accidentally break cargo-binstall for our users, so we decide to use a new env variable name that is specific for cargo-binstall.

I also added file-format as a dependency for more robust pem/der file detection and several cleanup.