SSL/proxy flexibility for corporate environment

[mihailik]

Motivation

Currently in a corporate environment you often have (a) authenticated HTTP/HTTPS proxies (b) SSL certificate spoofing.

Other registries like Maven for Java or NPM for JavaScript work, often requiring a bit of tweaking with environment variables and/or extra arguments.

Wasmer doesn't seem to work in any way at the moment. SSL certificates could be hardcoded into the binary? Or additional SSL/proxy arguments not expected? Whatever the cause, there is no visible solution at this point.

Proposed solution

Allow customising proxies, and customising the root SSL certificates. Conservatively that may come as command line options, forcing to be explicitly passed.

Alternatives

Another option could be to rely on the same environment variables as node.js for example. However, that can come with security implications, where end user may be having those options thinking they only affect node environment, and they are also kicking in in Wasmer.

These unexpected environment shifts can be most uncooperative in CI/CD environments causing mysterious behaviour changes.

Explicit command line argument are probably least disruptive.

Additional context

I am going to have a stab at it this Sunday, because that way I can at least have my own private clone of Wasmer tool to show POC of what we can do at my day job.

If everything goes smooth (a big if) we may adopt Wasmer for many interesting workloads internally. Which could benefit us: we have so many environments and jobs to run, and there's a mandate in 2025 to unify and make these data workloads more coherent and managed. But it could also benefit Wasmer, if the bosses like it and want to have some kind of Enterprise support deal etc. That's beyond my pay grade though, I'm focusing on the technical solution here.

[mihailik]

This PR deals with some of these issues, but still not working in a corporate locked-out environment:

#5091 Apply the proxy setting in wasmer config [merged]

I'll try to step through in debugger and see what's breaking.

[mihailik]

I've done a bit of research in the codebase, there seem to be 4 call sites that create reqwest::ClientBuilder::new() that need to be made aware of the extra parameters related to proxy, SSL certificate store and possible self-signed certificate opt-in.

lib/backend-api/src/client.rs
lib/cli/src/commands/package/download.rs
lib/wasix/src/http/reqwest.rs
lib/wasix/test/runners.rs

Only the first one already does handle proxy, the rest don't.

My suggestion is to put a common utility code that creates ClientBuilder into lib/wasix/http next to reqwest.rs. That would expect optional parameters for proxy, SSL etc.

Every one of the 4 places above will instead go via this new piece.

That way HTTP customisation can work coherently from one place.

---

I'm going to look further and try to implement that plan.

How does that sound?