-
Notifications
You must be signed in to change notification settings - Fork 364
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
fix: parsing crash on malformed pnpm lockfile #1327
fix: parsing crash on malformed pnpm lockfile #1327
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
pkg/lockfile/parse-pnpm-lock_test.go
Outdated
@@ -586,3 +586,13 @@ func TestParsePnpmLock_Files(t *testing.T) { | |||
}, | |||
}) | |||
} | |||
|
|||
func TestParsePnpmLock_Invalid(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you assert the packages that are expected to be extracted as part of the test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you give this a more descriptive name? it can still be terse, but currently "invalid" could mean a lot of things (the first that times to mind is that it's invalid YAML) - something like "with-invalid-path" would be enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Arguably the file is valid (I'm not an expert in pnpm lockfiles myself), but osv-scanner is failing to parse it correctly (and it crashes) on the [email protected] line.
This test file just validates that osv-scanner doesn't crash while reading it.
Happy to update the test case function / fixture file name to whatever you think captures this subtlety.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that this is an invalid key - while I'm also not an expect on pnpm lockfiles, I've not seen keys like this previously (if I had, then I'd have already covered this case in one of the 2-3 times I've effectively rewritten a part of this parser for a new lockfile version 😅) and it's also in a semgrep
fixture called "pnpm-error-key".
I think it is valid to call it with-invalid-path
(or maybe with-invalid-package-path
would be even better 🤔)
FYI, if you are using osv-scalibr, the latest version (v0.1.3) has fixed this issue already. We should still merge this fix in for osv-scanner |
@another-rex actually shouldn't this be treated like #1139? Afaik pnpm will never generate this itself, even if it doesn't error (which I've not tested) - so if we consider this something we should fix, I'd say we should land #1139 too |
I think for both the expected behavior is to return an error instead of panicing when encountering an invalid lockfile (partially because if we are encountering an unexpected line, the other information we extract might not be correct either). Looking at the implementation in this PR it seems like you are just ignoring the invalid package line when finding it, can you change it to return an error instead, thanks! That should match pre-#1139 if I understand correcty. |
Got it! Didn't know if you wanted to have partial results in response to a single invalid package path. Added tests and changed the fixture / test methods names. ps: Agree the file is invalid in the first place, but running Scalibr/osv-scanner against a filesystem with a semgrep checkout threw this panic and that was a bit of a bummer :) |
Co-authored-by: Gareth Jones <[email protected]>
Just need the CLA completed, and then this should be good to merge! |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1327 +/- ##
==========================================
+ Coverage 68.43% 68.44% +0.01%
==========================================
Files 183 183
Lines 17620 17629 +9
==========================================
+ Hits 12058 12067 +9
Misses 4898 4898
Partials 664 664 ☔ View full report in Codecov by Sentry. |
Running some internal approval processes. As soon as that done on our side, I'll sign the CLA. Apologies for the delay! |
CLA should be passing now, could you please re-run the checks? Thanks! |
Scalibr is crashing with a SIGSEGV while trying to parse this directory:
https://github.com/semgrep/semgrep/tree/develop/cli/tests/default/e2e/targets/dependency_aware
This is due to the lack of an array length check after the dependencyPath split.
Added failing lockfile as a test.
Steps to reproduce it