Scan all classpath entries

[DerGuteMoritz]

This allows using e.g. the Node Audit Analyzer (when enabled via the nvd.analyzer.node-audit-enabled config option) by passing package-lock.json as part of classpath. Note that the filtering in -main still takes care of removing directories and non-existing files. The comment there is updated to reflect the new behavior.

[gemini-code-assist[bot]]

Summary of Changes

Hello @DerGuteMoritz, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request broadens the capability of the dependency-check system by allowing it to scan all entries provided in the classpath, rather than being limited to only JAR files. This enhancement is crucial for integrating with other analyzers, such as the Node Audit Analyzer, which may require processing different file types like package-lock.json. The change ensures that while the scanning scope is expanded, the system continues to intelligently filter out irrelevant entries like directories or non-existent files during the initial classpath processing.

Highlights

• Expanded Scan Scope: The system will now scan all entries in the classpath, removing the previous restriction to only .jar files. This is achieved by removing the jar? predicate from the scan-and-analyze function.
• Node Audit Analyzer Support: This change enables the use of analyzers like the Node Audit Analyzer with files such as package-lock.json when they are passed as part of the classpath.
• Clarified Filtering Logic: An internal comment was updated to better explain that while all classpath entries are now considered for scanning, the initial classpath preparation still filters out directories and non-existent files.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

[^1]: Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

[vemv]

Hi!

Thanks for the contribution.

I'd prefer to do the least impactful change, namely only analyzing .jar and package-lock.json files.

Cheers - V

[DerGuteMoritz]

I'd prefer to do the least impactful change, namely only analyzing .jar and package-lock.json files.

Understandable! Note that this patch is motivated by wanting to use nvd-clojure in the context of a ReactNative project, for which the CocoaPods Analyzer would be desirable, as well. So I would then suggest to also allow *.podspec and Podfile.lock files.

However, note that all non-Java analyzers are disabled by default anyway so I'd wager that the impact of the more general patch should be tolerable. WDYT?

[vemv]

SGTM then, given that we're still filtering out directories, and it's rare to other have files as classpath entries.

[vemv]

Thanks!

Can you confirm that the build is green in your fork?

[DerGuteMoritz]

Can you confirm that the build is green in your fork?

Ah, this requires an NVD API token... I can try to run this locally with our organization's token. Or can you perhaps explicitly trigger the check explicitly in the scope of this repo? (I am not familiar with GitHub actions).

How about I also extend the integration tests to check a package-lock.json?

[vemv]

NVD tokens can be obtained instantly so it should be fairly easy to run that from a fork

Or can you perhaps explicitly trigger the check explicitly in the scope of this repo?

Your builds were triggered but fail probably due to secrets not being relayed for "external" contributors. Either way I don't have a lot of time to debug

How about I also extend the integration tests to check a package-lock.json?

Yes, that would be very much appreciated!

[DerGuteMoritz]

Alright, here we go: https://github.com/bevuta/nvd-clojure/pull/1