Repository navigation
Code Sign Release Artifacts #369
Description
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
Activity
ejsmith commentedon Jul 29, 2026
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:
Get-AuthenticodeSignature, or do they only require the.nupkgitself to be signed?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 commentedon Jul 29, 2026
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 commentedon Jul 29, 2026
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 commentedon Jul 29, 2026
@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.
hwetzel-ww commentedon Aug 20, 2026
Hi, we are experiencing more and more problems with Microsoft's "Smart App Control" which blocks access to some DLLs at runtime. In most times it affects DLLs without code signing. We can't eloborate why it hits sometimes this file and other times that file. So we wan't to deploy only signed assemblies.
I don't know if it is legally correct to sign your work with our certificate, it doesn't feel so.
niemyjski commentedon Oct 6, 2026
Thanks for sharing this! We looked into SignPath, and it does seem like a reasonable option for open source projects. It provides free signing with keys stored in an HSM and verifies that artifacts come from the project's CI build. One detail to be aware of is that the publisher would be SignPath Foundation, and each release requires manual signing approval. SignPath requirements
This addresses the certificate cost, but we'd still need to integrate and maintain signing in our release process. For now, we don't plan to add this upstream.
@hwetzel-ww, thanks for explaining the Smart App Control issue too. From our licensing side, Apache-2.0 permits you to build and redistribute your own copies, provided you follow its license and notice requirements. Signing your own build identifies your organization as the signer; the original copyright and attribution remain. Your certificate provider's terms also apply.
If you already have an OV certificate, you could include Exceptionless.Net in your existing signing process:
signtool verify /pa /vbefore packaging and deploying your application.This would tie the signatures to your organization's trusted publisher. If you try this and run into an issue with our build, please let us know.