OSS Index API token not working for gradle and maven

[capsulecorpor]

Precondition

• I checked the issues list for existing open or closed reports of the same problem.

Describe the bug
We are successfully authenticating to the OSS Index using the CLI tool but those same credentials do not work for the Maven and Gradle plugins. We arerunning scans in Gitlab CI/CD jobs in the following way:

CLI

.owaspdc.scan.cli:
  script:
    - check_node_duplicate_dependencies
    - dependency-check
      --noupdate
      --enableExperimental
      --disableNodeAuditCache
      --nodeAuditSkipDevDependencies
      --nodePackageSkipDevDependencies
      --ossIndexRemoteErrorWarnOnly true
      --format JSON
      --format HTML
      --suppression suppression.xml
      --exclude $EXCLUDE
      --scan .
      --ossIndexUsername $OSS_USERNAME
      --ossIndexPassword $OSS_API_TOKEN

Maven

.owaspdc.scan.maven:
  script:
    - maven_check_versions
    - ./mvnw org.owasp:dependency-check-maven:check -DdataDirectory=$DATA_DIR -DossIndexUsername=$OSS_USERNAME -DossIndexPassword=$OSS_API_TOKEN

Gradle

.owaspdc.scan.gradle:
  script:
    - *owaspdc-setup
    - gradle_check_versions
    - ./gradlew dependencyCheckAggregate -Ddata.directory=$DATA_DIR -Danalyzers.ossIndex.username=$OSS_USERNAME -Danalyzers.ossIndex.password=$OSS_API_TOKEN

As you can see, all three jobs use the same credentials, but the Maven and Gradle plugins are not able to authenticate.

Version of dependency-check used
The problem occurs using version 12.1.3 of the Gradle and Maven plugins

Log file
When reporting errors, 99% of the time log file output is required. Please post the log file as a gist and provide a link in the new issue.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

[marcelstoer]

I can confirm that supplying -DossIndexUsername=$OSS_INDEX_USER -DossIndexPassword=$OSS_INDEX_TOKEN (my env vars...) to the Maven plugin works just fine. That feature became available with 12.1.2 (#7640).

The problem occurs using version 12.1.3

I'd try using the latest before filing an issue.

the Maven and Gradle plugins are not able to authenticate.

Try running with debug output enabled (-X in Maven) to gather more information.

[capsulecorpor]

I can confirm that supplying -DossIndexUsername=$OSS_INDEX_USER -DossIndexPassword=$OSS_INDEX_TOKEN (my env vars...) to the Maven plugin works just fine. That feature became available with 12.1.2 (#7640).

The problem occurs using version 12.1.3

I'd try using the latest before filing an issue.

the Maven and Gradle plugins are not able to authenticate.

Try running with debug output enabled (-X in Maven) to gather more information.

When you were testing did you use a variable or did you define it as plain text? This maven documentation seems to indicate that variable replacement may not be possible, currently.

The passphrase and password elements may be externalized in the future, but for now they must be set plain-text in the settings.xml file.

[marcelstoer]

Oh...I see. This isn't about ODC in particular but about when and how the execution environment resolves environment variables. In my case I issue the mvn command in a GitLab CI pipeline. Hence, it's GitLab which resolves the $OSS_INDEX_USER variable and Maven sees plaintext.

[capsulecorpor]

Oh...I see. This isn't about ODC in particular but about when and how the execution environment resolves environment variables. In my case I issue the mvn command in a GitLab CI pipeline. Hence, it's GitLab which resolves the $OSS_INDEX_USER variable and Maven sees plaintext.

I am using Gitlab as well so perhaps that is not the issue after all...

[jeremylong]

There might also be an issue with the error reporting for invalid creds... See #7977.

[capsulecorpor]

Have you been able to reproduce the error for the gradle plugin using gradlew to invoke the command?

[chadlwilson]

I have not tried, but as a general rule you can't pass system properties like that to Gradle plugins without changing your own custom scripting to read them and set into extension configuration or tasks.

What do your build.gradles actually look like? If you were using the data directory before did you change your Gradle scripts to read a system property?

[chadlwilson]

According to the post st #7937 (comment) you can use -D system properties for Gradle but they are not the same as your example. Again, I have not tried it...

[capsulecorpor]

We have the Maven plugin working as expected now. The app team was using an outdated version of ODC in their pom.xml file. Thank you for your help on that front.

For the Gradle plugin I tried defining the properties in the root build.gradle file like so:

dependencyCheck {
    String ossUser = System.getenv("OSS_USERNAME")
    String ossPass = System.getenv("OSS_API_TOKEN")
    analyzers.ossIndex.username = ossUser
    analyzers.ossIndex.password = ossPass
}

and was able to get it to successfully run.

It is still not working in my CI script which is the desired result because we have multiple apps in our ecosystem and we wish to automate this process. Again, this is how I am running the scan for the Gradle plugin:

./gradlew dependencyCheckAggregate -Ddata.directory=$DATA_DIR -Danalyzers.ossIndex.username=$OSS_USERNAME -Danalyzers.ossIndex.password=$OSS_API_TOKEN

So defining it in the build.gradle works but when passing it as a parameter to gradlew it does not work.

[chadlwilson]

Did you try the system property names as in the comment I linked above? Again, the ones you have above definitely won't work.

If working as described, the system property mechanism is basically bypassing the entire Gradle plugin logic and going straight to Dependency Check core logic, which is likely why the naming is not consistent. (and also why you wont find it documented)

[capsulecorpor]

Sorry, I didn't see the difference in naming at first glance in that comment you linked. Making those changes did work for us. This ticket can be closed.

As an aside, is there a reason for those slight differences and is it documented anywhere?