Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RRFC] Locally computed integrity values in the lockfile #757

Open
ericcornelissen opened this issue Feb 15, 2024 · 0 comments
Open

[RRFC] Locally computed integrity values in the lockfile #757

ericcornelissen opened this issue Feb 15, 2024 · 0 comments

Comments

@ericcornelissen
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant