Can't run BlackDuck scan on a netcore 3.1 project - "Unable to install the nuget inspector from Artifactory"

Question

When running a BlackDuck scan on a netcoreapp3.1 project, I get this error:

[main] --- ======== Detect Issues ========
[main] ---
[main] --- DETECTORS:
[main] ---   D:\<-snip-my-local-path->
[main] ---     Not Extractable: NUGET - Solution
[main] ---        Exception occurred: com.synopsys.integration.detectable.detectable.exception.DetectableException: Unable to install the nuget inspector from Artifactory.
[main] ---
[main] --- ======== Detect Result ========
[main] ---
[main] --- Black Duck Project BOM: <-snip-scan-results-url->
[main] ---
[main] --- ======== Detect Status ========
[main] ---
[main] --- NUGET: FAILURE

Adding --logging.level.com.synopsys.integration=TRACE produced much more details, but nothing relevant for the problem, except for repeating the error message a bit more earlier:

Extractable did not pass: Exception occurred: com.synopsys.integration.detectable.detectable.exception.DetectableException: Unable to install the nuget inspector from Artifactory.

Detect version: 6.9.1 (so it is not this issue - although sounds similar - specifically, there's no No nuget inspector was found message in my case)

Also, the project can be built on the same machine with dotnet build or VisualStudio2019, with no problems, so that's not an issue with the project, or missing net-core-app build tools.

Answer 1

SOLUTION:

To get it running, I had to run the scan once, let it fail, then go to the tools/nuget folder, and unpack the 'dotnet inspector' .nuget file that was placed there. It's just a ZIP file, so many tools may be used for that. One important thing is: the directory name must be identical to the name of the file, including version. Just cut off the '.nuget' from the end of file name, and that makes the expected directory name.

---

PROBLEM DETAILS

Unfortunatelly, the details "why" are lost, even on the highest TRACE log level. It took me several hours of diagnosing and reading BlackDuck's code to find out what's going on, and find out that workaround.

Original exception details were lost, because error handling is flawed in this place and cuts off the exception details, leaving just the generic message text:

After analyzing the code and what was left in the logs and filesystem, I found out that the 'original' exception was thrown from here (because previous line was executed, and following line was not):

and any exception that had propagated from this DetectZipUtil.unzip() was then later catched and wrapped and re-wrapped several times in new exceptions, and finally landed in that try-catch-glue-strings-together that preserved only the 'message' coming from the last wrapper. Unfortunatelly, I don't have a debugger/etc to catch that, so I don't know what were the original exception's contents.

As you can see that last image, there's an "if folder exists" check, so it turns out that if we manually extract the nuget's contents, it will happily skip (faulty) decompression part, and just use what's in the folder. That's how I got that working.

There's one more interesting thing here: I suppose that's BlackDuck's "inspector", and I suppose that it was working for them, and all other people on the planet, then why not on my machine?

I checked what happens inside that DetectZipUtil.unzip():

so.. bummer. It's just standard java utils for ZIP files. It's possible that this path traversal from line 57 was thrown, but then, it would fail just the same on any other machine. And I guess it doesn't, since I couldn't find no posts about such issue in this scanner.

So either they published a non-standard ZIP file that is not handled well and did not notice this (very improbable I'd say), or it's something with my Java Runtime (uh?).

So I checked what Java Runtime was used, maybe it was old or something. And on this machine, it was running the BlackDuck scanner using openjdk-18.0.2_windows-x64_bin.zip. So pretty recent. It's possible that it would run just fine if I were using JRE or JDK. Unfortunatelly, I can't switch to them to re-test, and I've already spent more time on tracing this than I could.