Unable to sign bom

[g-sahil22]

Steps:

[tellison]

I'm also seeing this same error when attempting to sign our SBOM
See discussion at: adoptium/temurin-build#3158

[coderpatros]

Hi @tellison

Regarding the linked discussion and JSON signing,

Last time I checked there wasn't a JSF library available for .NET. That's why the CLI tool doesn't yet support enveloped signing for JSON format. It's been on my todo list for a while. But keeps getting bumped as it will take some care to make sure it is implemented correctly.

Are all the .NET runtime dependencies installed? In particular the required SSL library package?

[tellison]

Hi @coderpatros ,

I have tried it from the cli docker image where I assume that the dependencies are correct, and get the same outcome.

$ docker run -v "$(pwd)":/sbom cyclonedx/cyclonedx-cli keygen
Generating new public/private key pair...
Saving public key to public.key
Saving private key to private.key

$ docker run -v "$(pwd)":/sbom cyclonedx/cyclonedx-cli sign bom /sbom/sbom.xml --key-file /sbom/private.key
Loading private key...
Loading XML BOM...
Generating signature...
Unhandled exception: System.Security.Cryptography.CryptographicException: Could not create hash algorithm object.
   at System.Security.Cryptography.Xml.Reference.CalculateHashValue(XmlDocument , CanonicalXmlNodeList )
   at System.Security.Cryptography.Xml.SignedXml.BuildDigestedReferences()
   at System.Security.Cryptography.Xml.SignedXml.ComputeSignature()
   ....

[MatthewPowley]

I only had 30 mins to look at this as I was also getting the same error.
When built from Visual Studio in either Debug or Release configurations the tool works as expected.
When published as a self-contained, single file executable the observed error behaviour occurs.
I suspect that the trimming functions of the compiler are not correct.
I will try and have another look later this week.

[martinvanhensbergen]

I can confirm that setting true to false in the csproj file fixes this. In fact, when running the publish command, the compiler warnings already warn that trimming may result in issues.

As I am not a dotnet expert I am not sure what the fix should be. But considering the age of this issue, perhaps it is worthwhile to investigate further.

https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trim-self-contained

From the documentation:
To prevent changes in behavior when trimming applications, the .NET SDK provides static analysis of trim compatibility through "trim warnings." Trim warnings are produced by the trimmer when it finds code that may not be compatible with trimming. Code that's not trim-compatible may produce behavioral changes, or even crashes, in an application after it has been trimmed. Ideally, all applications that use trimming should have no trim warnings. If there are any trim warnings, the app should be thoroughly tested after trimming to ensure that there are no behavior changes.

Perhaps trimming should be disabled as it says that Xml parsers are non-trimmable.

[sej7278]

issue still seems to be present in 0.24.2 on debian sid

looks like merging #306 is the fix? works for me, although the binary is then about 3x the size.

[andreas-hilti]

@tellison @g-sahil22 Can you confirm that this is fixed in 0.25.0 thanks to 319467b?

[g-sahil22]

Hi @tellison ,