search

lirantal / lockfile-lint

Lint an npm or yarn lockfile to analyze and detect security issues
Apache License 2.0
776 stars 35 forks source link

Check integrity values for weak hashes #186

Closed ericcornelissen closed 6 months ago

ericcornelissen commented 6 months ago

Is your feature request related to a problem? Please describe. Not an active problem, but in the past I found that some (older) project I have had SHA1 integrity values in package-lock.json. While not the worst hashing algorithm, nowadays npm will(?) default to SHA512 hashes for the integrity value. From experience, npm does not seem to bother updating old integrity values for you (though I believe I last tried that on npm v7, which is pretty old by now).

I don't know how yarn and pnpm fare in this regard.

Describe the solution you'd like Have lockfile-lint report on sha1 (or other weak hashing algorithms) for integrity values in lockfiles.

Looking at the documentation for this I'm seeing some signs that sometimes weak algorithms are the only option. E.g. in the npm@v6 docs it states the git commit hash will be used for git sources, which are SHA1 hashes. If this is the case I'd propose to make the strong hash requirement conditional on the location from which the package is retrieved.

Describe alternatives you've considered For lockfile-lint, none.

In general, use other tooling (e.g. DevSkim, which can do this kind of check in general for a code base, and will find it in lockfiles).

lirantal commented 6 months ago

@ericcornelissen is the --validate-integrity flag not what you're looking for here? It requires the new 512 sha to be present. See here.

ericcornelissen commented 6 months ago

It is exactly :sweat_smile: Somehow I missed that, I think I was searching for "checksum" instead of "integrity"...

Thanks for the pointer!

lirantal commented 6 months ago

Awesome :-)

ericcornelissen commented 5 months ago

@lirantal asking here before opening a dedicated issue:

I'm using --validate-integrity now but am running into problems in a project where I use a dependency available only on the GitLab npm registry. Unfortunately, it seems that only provide SHA1 integrity values. Hence, I can't enable the option without a resolution (that I know of) available, even though I would like to enforce it for all other dependencies - current and especially future.

I didn't spot an option to declare exceptions or anything like that. Nor could I find a way to force npm to use a stronger integrity value. If those are both true, would you agree it makes sense to add an option for this? I'm thinking either having exceptions for a package or for a whole registry (at least in this case, I would ignore this rule for all packages from the GitLab npm registry).

lirantal commented 5 months ago

Agree it makes sense to add exception for both individual packages as well as registries. Thanks for raising Eric.