Bad exit code when no dependencies found on a maven file

[mohamnag]

given following (valid) maven pom file which is named as .flattened-pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>some-artifact-id</artifactId>
  <version>0.0.0-SNAPSHOT</version>
  <packaging>pom</packaging>
</project>

running osv-scanner:

/data # /osv-scanner -v
osv-scanner version: 1.3.1
commit: 7c08000dc3a0b1a690d46f70fa97b3fd87cb926b
built at: 2023-03-30T03:46:03Z
/data # /osv-scanner --lockfile "pom.xml:.flattened-pom.xml"; echo $?
Scanned /data/.flattened-pom.xml file as a pom.xml and found 0 packages
No package sources found, --help for usage information.
128

returns with exit code 128 which is incorrect. there is no found dependencies, so no vulnerabilities, and no errors. this is preventing us using OSV on lots of our CI pipelines as we have multi-module maven projects and all the root modules have almost always 0 dependencies. which means OSV scanning fails always.

any solution?

[oliverchang]

Hi! Thanks for the report.

We use exit code 128 only in the case where there are no dependencies found (https://github.com/google/osv-scanner/blob/898751b55d6372521911d327466a2901819942c1/cmd/osv-scanner/main.go#L149).

We didn't document this, which is incorrect. I created #351 for that.

We also had a recent PR to add --ok-empty to return 0 in such cases, but we rejected it at the time on the basis that it complicated the CLI interface and it was easy enough for clients to check this case explicitly (https://github.com/google/osv-scanner/pull/193#issuecomment-1422050194). Maybe it's time to revisit this.

Would it be easy at all to implement something similar to https://github.com/google/osv-scanner/pull/193#issuecomment-1422050194 on your end?

[mohamnag]

thanks for the feedback.

At the end of the day we could add something like || if [ $? -eq 128 ]; to where we are invoking osv anyway, but I would have personally vouched for something more explicit like --allow-empty or --ok-empty. even better would be to allow this be put on the config file that we pass to osv.

beside that still struggling to understand why a "no dependencies found" should be an error case, but thats something we can live with.

[oliverchang]

beside that still struggling to understand why a "no dependencies found" should be an error case, but thats something we can live with.

That's indeed a great point, and given that we have received this feedback more than once I wonder if we should consider this as bug as instead.

@another-rex WDYT? I think you added this in https://github.com/google/osv-scanner/commit/00182bd2e13baf5a02f2a053fe2c8abd14f040f8 ?

Was the intention to find lockfiles with invalid formats? We may want to distinguish between invalid lockfiles + valid lockfiles with 0 deps.

[another-rex]

One of the reasons for no dependencies found being an error is to allow users to see if they are using the scanner correctly.

For example, if you are using the directory scanning option, but renamed your lockfile to something that we don't automatically pick up, you might think you are free of vulnerabilities, but in-fact you are not scanning anything at all.

I do think having an option, either in the config or as a flag to allow empty does make sense.

[github-actions[bot]]

This issue has not had any activity for 60 days and will be automatically closed in two weeks

[github-actions[bot]]

Automatically closing stale issue