[RRFC] Locally computed integrity values in the lockfile

Motivation ("The Why")

Locally computed integrity values would allow projects to use the strongest available cryptographic hash for all the dependencies they have. In particular, when a registry doesn't support strong integrity values (i.e. sha1) a locally computed integrity value (e.g. using sha512) could improve the project's security.

Example

Currently, installing any package from GitLab's npm registry always results in a sha1 integrity value (source). A concrete example:

$ npm --version                 
10.1.0

$ echo "@gitlab-org:registry=https://gitlab.com/api/v4/packages/npm/" >>.npmrc

$ npm install @gitlab-org/jsfuzz
[...]

results in the following entry in package-lock.json:

{
  //...
  "node_modules/@gitlab-org/jsfuzz": {
    "version": "1.2.3",
    "resolved": "https://gitlab.com/api/v4/projects/19871264/packages/npm/@gitlab-org/jsfuzz/-/@gitlab-org/jsfuzz-1.2.3.tgz",

    // NOTICE: a 'sha1' integrity value
    "integrity": "sha1-QoDvllUJn7N7jMRUpYBSOmUGiwE=",

    "dependencies": {
      "deep-equal": "^1.1.0",
      "istanbul-lib-hook": "^3.0.0",
      "istanbul-lib-instrument": "^3.3.0",
      "nyc": "^15.1.0",
      "pidusage": "^2.0.17",
      "reflect-metadata": "^0.1.13",
      "yargs": "^14.2.0"
    },
    "bin": {
      "jsfuzz": "build/src/index.js"
    }
  },
  //...
}

There is, as far as I'm aware no mechanism for npm to instead put a sha512 hash in the lockfile.

How

Current Behaviour

Whenever the npm CLI puts integrity values in the lockfile, it uses the integrity value provided by registry.

Desired Behaviour

High level

The npm CLI should put locally computed integrity values -- computed using the "strongest" available, or a specified, hashing algorithm -- in the lockfile.

Flow

1. The npm CLI performs the installation process as it currently works (including, presumably, checking if the registry provided integrity value matches the package content).
2. The npm CLI recomputes the integrity value using the "strongest" available or the specified hashing algorithm and puts that value in the lockfile.
   • Of course, if the registry provided value is already using that algorithm, the implementation could skip recomputing it.

Configuration

At a minimum I would like to see an option that allows users to specify what hashing algorithm to use when installing.

I personally think it would make sense for the npm CLI to default to a "stronger" algorithm when no such option is provided. In the current state, where sha1 and sha512 are supported, this would mean defaulting to sha512. But, in case there's any concerns about this point, I don't think it's crucial.

Miscellaneous

• I want to point out that this change opens the npm CLI up to cryptography downgrade attacks (i.e. a project could end up with only "weak" sha1 hashes even when only fetching packages from a registry that provides "strong" sha512 hashes). I personally think the trade-off (being able to use stronger hashes when the registry only provides weak ones) is worth it, particularly since the option value is not the result of a negotiation (like in networking).
• I'm not suggesting any of this should automatically be applied to pre-existing, say sha1, integrity values in the lockfile (though I wouldn't mind it if there was some mechanism in the CLI to upgrade pre-existing integrity values). Though I would note that it might confuse users if they specify that sha512 hashes should be used only to find out that there's still (pre-existing) sha1 hashes in their lockfile.

References

• Related to https://github.com/lirantal/lockfile-lint/issues/187

The issue does not mention repository files, tests, or implementation entry points. Start by tracing npm CLI's installation flow and lockfile integrity handling, then compare the current registry-provided value with the proposed locally computed value and configuration options. Done means an agreed design for hashing behavior, configuration, compatibility, and downgrade risks.