Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
scan and report dependency groups of vulnerabilities #655
scan and report dependency groups of vulnerabilities #655
Changes from 6 commits
5e3e396
04ab40b
7f1b8d9
75b86f3
cc9b3ad
81584d5
b1e5ec0
8e3dc4f
4912b30
3e0ba51
0b0fa42
c1214c4
5bf495e
53c3016
a23817f
a9a213e
f414b44
a5cd81e
f7dce24
11d7a28
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Hmm, can we perhaps be more opinionated here in the table output, and just output e.g. "(dev)" in the cases where it is a dev dependency?
Users may not care about optional etc most of the time, and it would just clutter this table. If they do want the exact group details, they can use the JSON output.
We can define perhaps some kind of per-ecosystem function which just does:
or something similar per ecosystem?
@another-rex @G-Rath wdyt?
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.
Ecosystem is now a
string
can we still make it an interface?Or, we can have something like this?
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.
Agree we should just stick to a single output in the table output, but I think we should do it with a separate column.
I'm thinking "prod" column with a checkmark if it's a production dependency, and empty if not a production dep. This way it makes it applicable to all the other not "dev" named dependencies (e.g. optional in npm).
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.
Re column, I think the reason we went with a "(dev)" marker for now is that it because the column becomes redundant whenever we do/support any kind of filtering, and makes things inconsistent.
This is also somethign we can change at any time, given that there's no stability guarantees for the table/human readable output.
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.
I have added a method on
Ecosystem
to check if there isdev
group in the provided groups.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 pulling in
reflect
can be a big deal in Go, and at at least in the past with some methods (which tbh probably don't includeDeepEqual
) could trigger sizeable deoptimizations.I don't think this check is anything special and very internal so could be easily replaced with something like returning a pointer (so that we can then return
nil
), returning anerror
that we can eat here, or setting theName
to something like<not installed>
.I think that's probably worth doing either way so that we're not as dependent on the whole structure of
PackageDetails
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.
I modified the code here to check each field in
PackageDetails
and if they are all "empty". wdty?