The alternative is to continue with a process that's been demonstrably successful, despite it offending your sensibilities.

Banks are prepared to pay for it. People are prepared to do it. It meets the business needs. Change is massively high-risk in a hugely conservative industry.

Given the widespread existence of wasm sandboxing, rustc itself might want to think about alternative strategies for running compiler plugins. I suspect there'd be a performance hit with such an approach, but wasm tooling is getting really good; perhaps it is minor.

Apology appreciated, but unnecessary.

I don't want to derail a useful tool. It's worth going a bit beyond "hope" as a strategy, however, and thinking about if (how) this might be exploited.

I doubt anyone will be mining crypto in your sandbox. But perhaps you should think about detection; might it be possible to mask a malicious crate with a second that attempts to detect sandboxed compilation, for instance?

In any case, I think this still looks exceedingly interesting in the typical case, which is of detecting the impact of bugs from non-malicious actors.

I think you're trying to handwave at someone who knows more about the steganographic watermarking approach than you do.

Given the existence of macros, doesn't this let package maintainers run arbitrary code in the painter sandbox?

Yes. The sandbox gets whatever capabilities you expose to it.

Doesn't need to be a "traditional" container. Modulo noisy-neighbour issues, wasm sandboxing could potentially offer an order of magnitude better density (depending on what you're running; this might be more suited to specific tasks than providing a substrate for a general-purpose conpute service).