.NET NuGet - dotnet-deps cataloger not working with syft v0.94.0

[jeremytbrun]

What happened:
Using v0.92.0 I can generate an SBOM using the dotnet-deps cataloger. After updating to v0.94.0 I can no longer generate an SBOM using the dotnet-deps cataloger pointed at the exact same directory.

syft.exe .\My.Rest.Api\My.Rest.Api\bin\Debug\net6.0\ -o cyclonedx-json=.\my.rest.api.json --catalogers dotnet-deps -vv

WARN cataloger failed cataloger=dotnet-deps-cataloger error=unable to determine root package from deps.json file: \My.Rest.Api.deps.json location=\My.Rest.Api.deps.json

Here is a sample section of the My.Rest.Api.deps.json file I am using. This works with v0.92.0, but does not work with v0.94.0.

What you expected to happen:
I expected a cyclonedx SBOM to be generated.

Steps to reproduce the issue:
Install v0.92.0 and generate cyclonedx SBOM successfully. Install v0.94.0 and it longer works.

Anything else we need to know?:

Environment:

• Output of syft version:

Working
Application: syft
Version: 0.92.0
BuildDate: 2023-09-27T15:40:42Z
GitCommit: 8f57d22
GitDescription: v0.92.0
Platform: windows/amd64
GoVersion: go1.21.1
Compiler: gc

Not Working
Application: syft
Version: 0.94.0
BuildDate: 2023-10-20T17:21:07Z
GitCommit: 8f6bdde
GitDescription: v0.94.0
Platform: windows/amd64
GoVersion: go1.21.3
Compiler: gc

• OS (e.g: cat /etc/os-release or similar):
  Windows 11 Enterprise 21H2

[spiffcs]

Thanks @jeremytbrun! Similar issue to #2255 - we'll get a bug fix contributed and released as soon as we can here.

[jeremytbrun]

Thanks @jeremytbrun! Similar issue to #2255 - we'll get a bug fix contributed and released as soon as we can here.

Thanks @spiffcs . FWIW I just downloaded release 0.96.0 and I still have the issue.

Application: syft
Version:    0.96.0
BuildDate:  2023-11-09T14:04:09Z
GitCommit:  0891d35e0774f175e3a3f170edcce9ad2f4f015b
GitDescription: v0.96.0
Platform:   windows/amd64
GoVersion:  go1.21.3
Compiler:   gc

syft.exe . -o cyclonedx-json=./sbom.json --catalogers dotnet-deps

WARN cataloger failed cataloger=dotnet-deps-cataloger error=unable to determine root package from deps.json file: \bin\Debug\net6.0\My.Rest.Api.deps.json location=\bin\Debug\net6.0\My.Rest.Api.deps.json

[tgerla]

Hey @jeremytbrun, thank you for the details. I think we were wrong about the connection to #2255, this might be a separate problem. Are you able to share your deps.json file with us? That will be helpful for us to reproduce and fix. Thanks!

[jeremytbrun]

Hey @jeremytbrun, thank you for the details. I think we were wrong about the connection to #2255, this might be a separate problem. Are you able to share your deps.json file with us? That will be helpful for us to reproduce and fix. Thanks!

My.Rest.Api.deps.json

[willmurphyscode]

Hi @jeremytbrun, thanks for attaching the deps.json! I've been able to confirm that this is a Windows-specific bug:

Works on mac/Linux:

mkdir syft2264
cd syft 2264
wget https://github.com/anchore/syft/files/13369564/My.Rest.Api.deps.json
syft --select-catalogers dotnet -o cyclonedx-json=cdx.json .
jq '.components | length' cdx.json
 # 203 is printed

Seems to have found 203 packages and never printed WARN cataloger failed cataloger=dotnet-deps-cataloger error=unable to determine root package from deps.json file.

But on windows:

mkdir syft2264
cd .\syft2264
Invoke-WebRequest -Uri "https://github.com/anchore/syft/files/13369564/My.Rest.Api.deps.json" -OutFile "My.Rest.Api.deps.json"
syft.exe .

Results in:

[0000]  WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
[0000]  WARN cataloger failed cataloger=dotnet-deps-cataloger error=unable to determine root package from deps.json file: \My.Rest.Api.deps.json location=\My.Rest.Api.deps.json
No packages discovered

Given that it's windows specific, we have 2 more places we can start looking:

1. path separator issues - there's a hard-coded / somewhere preventing us finding the deps.json
2. encoding - I know .NET (at least when I worked with it some time ago) and Powershell use UTF-16 as their default encoding, but many systems now expect UTF-8.

I think the path is probably more likely, since I don't know why Invoke-WebRequest would take it upon itself to re-encode the file, but those are the two places we will check next.