anchore
dotnet-deps-binary-cataloger DLL to package version matching is too precise
What happened: When you run syft scan using the dotnet-deps-binary-cataloger with dep-packages-must-have-dll: true, the sbom only includes the dlls entries because the assembly/dll versions do not match the semantic versions uses by the packages, this behaviour is also wrong for the other dotnet options that default to true. This is not intended behaviour because these versions are non-existent in package sources such as NuGet, and they should map to a semantic version.
What you expected to happen: Youd expect 8.0.1202022222 to match 8.0.12 I am not sure if everything is rounded in one direction.
Steps to reproduce the issue: Run syft scan against a dotnet publish output folder with a syft config that has the deps-pacakges-must-have-dll set to true or has default values for the other flags.
Anything else we need to know?:
Which is actually 8.0.14
Environment:
- Output of
syft version: 1.31.0 - OS (e.g:
cat /etc/os-releaseor similar): win-x64
Hi @WesHaze thanks for the bug report!
Run syft scan against a dotnet publish output folder with a syft config that has the deps-pacakges-must-have-dll set to true or has default values for the other flags.
The dotnet ecosystem has a lot of different ways of doing things, and I'm not confident of reproducing the issue from these instructions. Do you think you could make or find an open source repo that exhibits this problem?
It sounds like you're running a directory against a directory with build artifacts in it. Is that correct?
Hey Will, I am indeed running the directory scan with the afforementioned cataloger against a publication output folder.
You can use one of the included test projects and I'd reckon you could use 99+% of open source repos that use dotnet and have a few package references.
As an example I've published the following dotnet test project that is included in syft in a non self contained manner using:
dotnet publish --runtime win-x64 --self-contained false.
But really any publication method that results in a deps.json file will come with dlls as dotnet bases dll loading on this file.
What happens is that the assembly version will be compared against the version of the package, but the assembly version roughly matches the package version (this is also not always true but works for most cases) so the exact comparison fails. Leaving the sbom without any of the package listings, thus resulting in a DLL-sbom.
This comparison happens in https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/dotnet/deps_binary_cataloger.go#L275
Hey @WesHaze, looking at these versions, is the last number actually part of the version or is it something like a build number that just happens to be included in the version string? Is there any documentation you could point to that outlines the specific rules we should be using here? In the description you mention: 8.0.1202022222 should match 8.0.12, is this actually 8.0.12.<something>, or is it really all concatenated together into a single large number and if so how are we supposed to know what is part of the number vs not?
@kzantow the last number is just the revision number.
source
Nuget follows semver 2 which does not include the revision number and there's also no guarentee that the assemblyFileVersion's Major.Minor.Patch align with the lib's, as seen below:
It suggest seeking out known users of this feature and reconsidering the functionality or it's name as quality here would be really hard to achieve, it's open source so I suppose there's a lot of ways for things to reach main but maybe we should also reconsider the review proces if quality is something we deeply value. I think I have/had another issue that proposed not including the dll's in the scan maybe this or the inversion of this with nuget lookups is a more robust way of dealing with the issue.
Hi @WesHaze,
I'm really not sure I understand your suggestion. It sounds like there are two kinds of versions of dotnet DLLs, one AssemblyVersion, and one AssemblyFileVersion? It sounds like the one that should be used for vulnerability matching is the AssemblyVersion, not the AssemblyFileVersion? And there's no guarantee that assembly file version has anything to do with anything, and we should just drop it / ignore it?
It also sounds like they both consist of 4 fields: major, minor, build number, and revision see docs. Is that right?
You'd expect 8.0.1202022222 to match 8.0.12
It also sounds like we should handle version comparison differently? Maybe 8.0.1202022222 should match 8.0.12 because the major and minor versions are the same? There seems to be no delimited between the build number and the revision, so I'm not sure how to separate them.
Please feel free to come to an upcoming community meeting and help us understand what should be different here.