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

Add option to exclude packages from the `--validate-integrity` check #188

Closed ericcornelissen closed 4 months ago

ericcornelissen commented 4 months ago

Description

Add a new option available on the CLI as --integrity-exclude which allows user to disable the --validate-integrity check for specific packages.

Also, format the table in the lockfile-lint package's README. Some more formatting happened as a result of commit hooks.

Types of changes

Related Issue

187

Motivation and Context

I have a project where I use a dependency available only on the GitLab npm registry. This registry only provides SHA1 integrity values and so dependency installed from there are rejected when using the --validate-integrity option. As a result I can't use --validate-integrity to at least enforce strong integrity values for dependencies from other registries.

How Has This Been Tested?

Unit testing: updated the tests and ran npm run test. I was using Node.js v20.9.0 while working on this.

Screenshots (if appropriate):

n/a

Checklist:

cute animal

codecov-commenter commented 4 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (7958b39) 97.98% compared to head (afcefd9) 98.01%.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #188 +/- ## ========================================== + Coverage 97.98% 98.01% +0.02% ========================================== Files 13 13 Lines 398 403 +5 Branches 93 96 +3 ========================================== + Hits 390 395 +5 Misses 8 8 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

lirantal commented 4 months ago

Superb. Thank you Eric!

ericcornelissen commented 4 months ago

It seems the mocked data in validators.integrityHashType.test.js isn't quite representative of real-world data. In particular, packageName doesn't look like "typescript" but rather like "typescript@{version}-{hex-value}" - hence the implementation here doesn't work, apologies :sweat: I'll submit a followup PR with a patch

lirantal commented 4 months ago

Ahh, good catch and thanks for the quick follow-up!