Skip to content

SPDX parsing improvements #335

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.

Sign up for GitHub

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

Jump to bottom
Closed
2 of 3 tasks
oliverchang opened this issue Apr 11, 2023 · 2 comments · Fixed by #349
Closed
2 of 3 tasks

SPDX parsing improvements #335

oliverchang opened this issue Apr 11, 2023 · 2 comments · Fixed by #349
Labels
enhancement New feature or request

Comments

@oliverchang
Copy link
Collaborator

oliverchang commented Apr 11, 2023 •
edited
Loading

Tracking bug for a number of improvements to our current SPDX parsing

  • We should warn with a more specific error message when there are no PURLs available in the SBOM.
  • Currently for passing SPDX JSON files to -L we expect ".spdx.json" in the filename. Otherwise we will silently report that there are no packages. We should be more flexible here since we've seen a few instances/complaints for this.
  • We don't propagate detailed errors messages back to the user when a malformed SPDX file is provided (

    osv-scanner/internal/sbom/spdx.go

    Line 66 in cfaf9f8

    return ErrInvalidFormat
    )
@oliverchang oliverchang mentioned this issue Apr 11, 2023
Closed
@oliverchang oliverchang added the enhancement New feature or request label Apr 11, 2023
@oliverchang oliverchang mentioned this issue Apr 12, 2023
Merged
@anotherbridge
Copy link

@oliverchang For your second point I would suggest that first an appropriate error message should be placed, since if the tool reports that no packages were found the first point one would think of is that something within the SBOM is incorrect and not that the filename is non conformant.

oliverchang added a commit that referenced this issue Apr 13, 2023
@oliverchang
SBOM parsing improvements. (#339)
dd3f7a5 
Addresses part of #335

1. Be more relaxed about filename matching the spec when the SBOM is
explicitly passed via --sbom since we've seen multiple complaints from
different users about this.
2. Surface all parse errors when SBOM parsing fails (and we're
explicitly scanning via --sbom).

This will look something like:

```
Failed to parse SBOM using all supported formats:
failed to parse SPDX:
        failed trying json: failed to parse Supplier 'Google LLC'
        failed trying rdf: found extra chars before tag start
        failed trying tv: no colon found in '{'
failed to parse CycloneDX:
        failed trying json: invalid BOMFormat
        failed trying xml: XML syntax error on line 74: expected attribute name in element
No package sources found, --help for usage information.
exit status 128
```
@oliverchang
Copy link
Collaborator Author

Thanks @anotherbridge. We're actually going to be more relaxed on the filenames here (in #339) to make the scanner easier to use. Point 3 in this bug (more detailed parsing errors) was also implemented.

This should go out in our next release.

@another-rex another-rex mentioned this issue Apr 17, 2023
Merged
another-rex added a commit that referenced this issue Apr 18, 2023
@another-rex
Better SBOM documentation and error message (#349)
2c101c1 
Closes #335 #290 #93 #347 (Turns out we have a bunch of duplicate issues
all roughly tracking the same thing)

---------

Co-authored-by: Hayley Denbraver <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Better SBOM documentation and error message another-rex/osv-scanner
2 participants
@oliverchang @anotherbridge