Prune vulnerable libhdf5 JUnit JAR from project

[aphahn]

Summary

A JUnit JAR in this repo is vulnerable to CVE-2020-15250, a local information disclosure vulnerability.

Details

This package includes includes libhdf5. We use gdal-async (thank you!), but Google Artifact Registry flagged a vulnerability in our resulting Docker image.

It says that the included JUnit JAR was vulnerable to CVE-2020-15250.

The offending JAR lives here.

I don't think this library actually executes the code from this JAR. To avoid having other downstream projects get flagged for security vulnerabilities, perhaps the libhdf5.sh script could prune down the amount of the hdf5 tarball it includes in this project.

Alternatively, would you be willing to prune down what is included in the NPM package?

Impact

This is a "local information disclosure vulnerability". I'm not sure if this affects this project, but other downstream projects may be getting false positives alerts as a result of including this vulnerable library.

[mmomtchev]

This junit.jar is simply part of the HDF5 distribution, it is not used in any way in this project.

[aphahn]

I see. Would you be open to removing it from the NPM package, then? It seems like it's not necessary for users of the package to download it.

Perhaps we could add deps/**/*.jar to the .npmignore file (like how dependencies' Python and shell scripts are handled)?

[cakoose]

(I work with @aphahn and deal with security/compliance stuff.)

@mmomtchev: Totally agree that there is no actual vulnerability here.

The issue is that it causes some friction in our security workflow. We use two tools to identify vulnerable dependency versions: GitHub's Dependabot and GCP's container vulnerability scanner.

The tools help a ton by notifying us if any of our packages have reported security vulnerabilities. (I'd love if they were smart enough to identify whether there was a true vulnerability, but they're nowhere near being able to do that yet.)

So when the tool detects a vulnerable package, we have two options:

1. Figure out how to upgrade/remove the vulnerable package.
2. Suppress the warning.

The problem with option 2 is that the suppression rules are often blunt instruments, e.g. "ignore JUnit vulnerabilities", which could later come back to bite us. So we try hard to upgrade/remove the vulnerable package.

One idea we had was to removing the JAR (and maybe the entire containing folder) from the NPM bundle, which seemed to have a nice side benefit of making the bundle smaller. (Though of course we have no idea how much initial+ongoing effort and risk this entails for you!)

[mmomtchev]

I think that what wrecks havoc the most is the total inability of the geo community to admit that they have been made into brain-damaged criminals and that this project has become a monument to their lack of will to act.

You become what you behold.