Sandboxing install-time code execution

In the wake of Sha1 Halud much of the discussion has centered around cooldown, but I'm looking to address another aspect of package installation, that of install-time code execution.

I'm wondering about the feasibility of implementing something like bundle update|install --cache-only, which would work similarly to bundle cache --no-install except that it would first perform any version resolution.

Critically, the new --cache-only flag would guarantee that no code contained inside any gem (part of the bundle) would be executed yet. It would only download the package(s) into the vendor location from where they can later be installed with bundle install --local.

This scheme would have two immediate benefits:

1. Finalizing the installation could be run with reduced privileges, i.e. in a sandbox. This would allow removing package registry credentials from the env and disabling network access, since both are usually not needed outside of package download. [^1]
2. It would simplify and make more reliable a comparison (audit) of old vs new gem contents; if the --cache-only command would write a tentative Gemfile.lock (maybe Gemfile.cache.lock) then a tool could show a full diff of exactly the changes that bundle install would apply.

It would ideally be possible to configure things (using bundle config) so that two-step upgrades and installations are enforced, i.e. so that bundle update|install without --cache-only flag fails when run outside a sandbox. This could be achieved through a customizable script that might ensure certain env vars are absent or pinging a given host fails.

Finally, ideally only gems on an allowlist would be permitted to execute code at all during installation.

Needless to say none of this would protect against malicious runtime code, aside from simplifying audits, but still be valuable seeing that install-time and runtime environments can differ, with different threat models.

[^1]: I'd expect that some gems would fail to install without network access, but that could be addressed separately in the affected gems.

No files or tests are named. Start by tracing the bundle install, bundle update, and bundle cache --no-install command paths, then review how bundle config handles install behavior; first narrow the proposal to a defined cache-only workflow and acceptance criteria for preventing install-time code execution.