Runtime.InteropServices - StrongNameSigning
Closed this issue · 13 comments
We are trying to migrate to Net6 and want to consume this NugetPackage instead of the original System.Runtime.InteropServices.
Since we need to generate code and register this code at runtime, we need to add the .dll to our deliverables.
Since we are StrongName-Signing our product, we can only deliver packages, that are strongName-Signed as well.
==> We want a strongName-Signed version of the dSPACE.Runtime.InteropServices Package.
From the Microsoft documentation:
This guidance is specific to publicly distributed .NET libraries, such as .NET libraries published on NuGet.org. Strong naming is not required by most .NET applications and should not be done by default.
https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming
From the Microsoft documentation:
When the identity of the publisher of the code is desired, Authenticode and NuGet Package Signing are recommended. Code Access Security (CAS) should not be used as a security mitigation.
There is no plan to use StrongNameSigning.
Also from another Microsoft documentation:
For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.
https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named
This implies, that a strong name is only part of the assembly identity, but the runtime will ignore this part. Hence there is no real benefit in strong name signing assemblies anymore.
The best practice should be to apply a digital signature to the assembly, if possible.
Ok, in that case I have a different understanding from you: Because I read on the same page the following things:
You should strong name your open-source .NET libraries. Strong naming an assembly ensures the most people can use it, and strict assembly loading only affects .NET Framework.
...
This guidance is specific to publicly distributed .NET libraries, such as .NET libraries published on NuGet.org. Strong naming is not required by most .NET applications and should not be done by default.
And that tells me that even if we don't create any security benefit from strong name key signing, we should do it to allow for better compatibility with application which require it because the application is still in .NET Framework 4.8
You're bringing up a good point here.
Unfortunately, @NikoBergemann is strictly asking for support for his strong name signed dotnet 6 application.
Also, the hint is
CONSIDER adding the strong naming key to your source control system.
It should be not that easy, since the private key should be that, what the name supposes: Private.
It actually would bring up some infrastructural changes to this project, which might take some time.
/cc @marklechtermann
We would have to designate a public/private key pair for the strong name key signing which would work with GitHub Encrypted Secrets
https://docs.github.com/en/actions/security-guides/encrypted-secrets
Great. But do not forget that we need a testing key for local reproducability or we need delay signing ...
Given that we want the identity benefits but don't require any security we could also use a "private" key which is publicly available in the repository.
We can create our own key pair used only for the dscom project and add it to the git repository.
That's suggested in @carstencodes 's article: https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named
If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.
For our purposes this would be the easiest solution and other open source projects seem to handle it similarly. For example:
Sorry for being blunt, but in this case the strong name really has no meaning.
Creating the strong name key as publicly available will enable anyone to create the assembly with that strong name. Hence a proof of origin can no longer be guaranteed.
The run-time does not verify it any longer.
Hence the only reason to add the strong name is to have a strong name. I see no benefits from having one.
But lately, as the principle-maintainer, it's your decision to take.
I agree, the strong name does not have any real meaning anymore for future versions.
Everything I could find tells the same story:
- https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming
- Microsoft says it should not be used for security.
- .NET >5 does not evaluate the signature.
The official documentation says:
✔️ CONSIDER adding the strong naming key to your source control system.
A publicly available key lets developers modify and recompile your library source code with the same key.
...
When the identity of the publisher of the code is desired, Authenticode and NuGet Package Signing are recommended. Code Access Security (CAS) should not be used as a security mitigation.
It's solely required for maintaining compatibility with .NET Framework 4.8 applications which are strong name signed themselves. Because if your application is installed in the GAC your application must be strong name key signed.
So for me it's a feature to support old legacy code which require SNK code:
One important aspect of strong naming is that it's viral: a strong named assembly can only reference other strong named assemblies. If your library isn't strong named, then you have excluded developers who are building an application or library that needs strong naming from using it.
It's solely required for maintaining compatibility with .NET Framework 4.8 applications which are strong name signed themselves. Because if your application is installed in the GAC your application must be strong name key signed.
Let's hope that dscom will not be added to the GAC.
Nevertheless I'm not quite sure if there is a use case for dscom in .NET FX.
I'll put it this way.
If no one minds, then you should implement this. @SOsterbrink
I should get around to fixing it tomorrow.