Add user-configurable preferences for handling self-updating modules

[coreybutler]

It is possible to manually revalidate global modules that self-update using nvm reshim, but this is not an ideal workflow. It is possible to auto-validate self-updating modules, but this can be exploited by compromised packages.

There should be a policy allowing or disabling auto-revalidation, as well as an allow/block-list to configure automatic revalidation of trusted global modules.

It also happens with some commands that can update themselves.

$ nvm --version
v2.0.1-hotfix.1
$ npm i -g opencode-ai@1.18.30
$ opencode upgrade
$ opencode
NVM blocked package-manager execution because a delegated command could not be trusted.

Command: opencode
File: ~\AppData\Local\Author Software\nvm\installs\v26.8.1\opencode.cmd
Reason: delegated script changed since it was trusted
Action: Run `nvm reshim` (re-signs package-manager scripts) or `nvm doctor --autofix`.
If this change was unexpected, contact your administrator and review NVM event logs.
Event code: NVM4306

and nvm reshim resolves the issue. Blocking a self-updatable program after updating may be a good idea, but it would be good if we could whitelist some executables.

Originally posted by @ziyuang in #1379

[coreybutler]

@ziyuang - I've added this feature and used your example as the test.

By default, nothing will be trusted. There is a configuration option to allow, deny (default), or prompt. The example below shows the "prompt" configuration.

In this example, opencode is automatically added to the trusted module list. When configured to allow, all self-update changes are allowed, but a native desktop notification will be displayed whenever the underlying module is changed to create awareness. When configured to deny, the error message will be displayed.

The allow-list can be modified directly and does not require a module be installed, so you can configure whatever you like.

• nvm firewall trust module package_a package_b etc
• nvm firewall untrust module package_a package_b etc

reshim.exe has been modified to support the trust list as well.

Note

Certified build governance supports policy overrides, so admins can enforce trust lists. Governance will also support a dynamic trust list (a secure/validated URL).

I'm leaving this here for feedback, but I feel pretty confident in the design of this feature. The goal was to balance security/awareness with developer ease.

[ziyuang]

It is a bit weird on my side. I cannot run opencode twice (may not be the problem with the fix itself):

$ nvm --version
v2.0.1-hotfix.2
$ npm uninstall -g opencode-ai
$ nvm reshim
$ opencode
opencode: The term 'opencode' is not recognized as the name of a cmdlet...
$ npm i -g opencode-ai@1.18.30
$ opencode  // runs normally
$ opencode
NVM blocked package-manager execution because a delegated command could not be trusted.

Command: opencode
File: ~\AppData\Local\Author Software\nvm\installs\v26.8.1\opencode.cmd
Reason: delegated script changed since it was trusted
Action: Run `nvm reshim` (re-signs package-manager scripts) or `nvm doctor --autofix`.
If this change was unexpected, contact your administrator and review NVM event logs.
Event code: NVM4306

But then later

$ nvm reshim
$ opencode upgrade
$ opencode  // runs normally; the firewall prompt doesn't appear
$ opencode  // runs normally too

[coreybutler]

@ziyuang the behavior you experienced was caused by an issue with reshim. I fixed it in v2.0.1-beta.1.

This feature has now been implemented in https://github.com/nvm-windows/nvm/releases/tag/v2.0.1-beta.1. The documentation will be updated soon, but the feature is streamlined and mostly transparent in the new build.