gedhrel
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.
I think you vastly overestimate the separability of these systems.
Picture 10,000 lines of code in one method, with a history of multiple decades.
Now picture that that method has buried in it, complex interactions with another method of similar size, which is triggered via an obscure side-effect.
Picture whole teams of developers adding to this on a daily basis in realtime.
There is no “meaningful progress” to be made here. It may offend your aesthetic sense, but it’s just the reality of doing business.
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.