Code Sign Release Artifacts

[elachlan]

Code signing release DLLs has come up in several security reviews. It would be great if the Exceptionless DLLs were code signed (Authenticode).

Other projects have used dotnet sign with github actions to automate release signing:
https://github.com/dotnet/sign/tree/main

[ejsmith]

Thanks for raising this. Before we add the signing infrastructure, could you share more detail about the security-review requirement?

Exceptionless assemblies are already strong-name signed, although strong naming is an identity/compatibility mechanism rather than a security boundary. Authenticode-signing every DLL inside an ordinary NuGet library is less common than signing Windows applications, installers, drivers, or binaries that must satisfy AppLocker/WDAC publisher policies. NuGet package author/repository signing is also a separate mechanism from Authenticode-signing the assemblies inside the package.

A few specifics would help us choose the right control:

• Which security review, standard, or customer requirement is requesting this?
• Are they explicitly checking the DLLs with SignTool or Get-AuthenticodeSignature, or do they only require the .nupkg itself to be signed?
• Is publisher-based AppLocker/WDAC allow-listing a requirement?
• Which Exceptionless packages and target frameworks need signatures?
• Are there requirements for the certificate issuer, subject, timestamp service, or key storage?

Depending on the answers, the appropriate solution could be Authenticode signatures on every packaged DLL, NuGet author signing, or improving publishing provenance with NuGet Trusted Publishing/OIDC. The requested verification method would give us the clearest acceptance criterion.

[elachlan]

We require Authenticode signatures on every packaged DLL. We deploy the packages as a part of a winforms application. The signing is to help establish that the file hasn't changed post build.

We deploy our own DLLs codesigned using signtool and an OV code signing cert.

This is against the OWASP standard - DA8 : https://owasp.org/www-project-desktop-app-security-top-10/

[ejsmith]

Thanks for the additional context. We took a closer look at how comparable, widely used .NET SDK packages are distributed, and Authenticode-signing every assembly inside an ordinary NuGet library does not appear to be common practice.

Adding this would require us to introduce and maintain a public code-signing service, identity validation, signing and verification steps, and the associated certificate and service lifecycle. Even with a managed option, that creates recurring monetary cost and ongoing release and maintenance overhead for a small open-source project. NuGet.org already repository-signs the package itself, although we understand that this is not the same as Authenticode-signing each deployed assembly.

Given the cost and how uncommon per-DLL Authenticode signing is for comparable .NET libraries, we are not convinced that adding and maintaining it upstream is proportionate for the project at this time.

Because the SDK is open source, an option for environments with this specific policy is to build the assemblies from source within your own controlled pipeline and Authenticode-sign those internally built binaries using your organization’s existing code-signing certificate. That would give you the required tamper detection while tying the signatures directly to the build process and publisher trusted by your deployment policy.

We appreciate you explaining the requirement and use case. We will keep the request in mind if broader ecosystem or customer demand changes, but we do not plan to add per-DLL Authenticode signing at this time.

[elachlan]

@ejsmith I appreciate the response. There are zero cost options for open source projects. Example https://signpath.org/ which provides code sign certificates and hosted signing services.