Request - strong naming of NuGet packages

rdewaele commented 1 year ago

Description

Would it be possible to provide strong named assemblies for the CDKTF libraries published on NuGet?

My current impression is that this would be according to Microsoft guidelines: https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

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.

Thank you for your consideration.

References

No response

Help Wanted

[ ] I'm interested in contributing a fix myself

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

mutahhir commented 1 year ago

@jsteinich do you have any insights / opinions on this? Primarily, are there any downsides for strong naming that we should be aware of?

jsteinich commented 12 months ago

I've never personally used them. I've also not really come across libraries actually doing it. From https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named:

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.

rdewaele commented 12 months ago

I've never personally used them. I've also not really come across libraries actually doing it. From https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named:

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.

I am also pleased that the newer runtimes no longer have a need for strong naming. However, .NET Framework applications are still very common, where strong naming still matters. This is why their recommendation to strongly name open-source libraries (I quoted above) includes the notion that this only affects .NET Framework.

For us, all applications we have developed for clients involving .NET Framework, also involve strongly named packages. So far we have come across one (not counting CDKTF) dependency that we needed that was not, which we had to disassemble, recompile and publish to a private repository to be able to use. Because this is anecdotal, I can not be sure how representative this is for the CDKTF audience, but it our personal experience.

Note: We also saw different approaches in how project tackle this issue. E.g. DotNetRDF is strongly named by default, but Scriban publishes two packages: Scriban and Scriban.Signed. I am not sure what the rationale is for the split.

EDIT: .NET Framework also has this, ehm, diverging support policy tying it to that of Windows, so it's not going anywhere anytime soon it seems: https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework

EDIT 2: We strong name our assemblies by adding the following to a top-level (i.e. git repository root) Directory.Build.props file, which gets included by other Directory.Build.props files (e.g. src/Directory.Build.props or tests/Directory.Build.props):

<!-- sign unless explicitly disabled -->
<PropertyGroup Condition="'$(UseStrongName)' != 'false'">
    <SignAssembly>true</SignAssembly>
    <AssemblyOriginatorKeyFile>$(SolutionKeyFile)</AssemblyOriginatorKeyFile>
</PropertyGroup>

For generating the key, we use sn that comes with Mono (because I like working in Linux, I suppose :sweat_smile:):

~❯ sn -k example.key
Mono StrongName - version 6.12.0.0
StrongName utility for signing assemblies
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.

A new 1024 bits strong name keypair has been generated in file 'example.key'.

For us, this works with people developing on Windows, Linux, and I think I built it on macOS that one time. Linux-based CI that publishes the strong named assemblies. (These are all .NET Standard, and get used by clients in .NET Framework environments.)

EDIT 3: Note that (as indicated by the MS docs) for OSS it's fine to keep the key in the repository, of course as long as it has not been used for confidential purposes in the past. Example: https://github.com/dotnetrdf/dotnetrdf/blob/main/Build/dotNetRDF.snk It may be interesting to note that they considered no longer strong naming with 3.0.0, but ultimately decided against it given the official recommendation and their target audience. (https://github.com/dotnetrdf/dotnetrdf/pull/546 & https://github.com/dotnetrdf/dotnetrdf/issues/541)

jsteinich commented 11 months ago

cdktf isn't compatible with .NET Framework. It should be able to reference any .NET Standard libraries (strong-named or not), but it won't be available to use .NET Framework environments (regardless of strong-naming).

xiehan commented 11 months ago

Since cdktf isn't compatible with .NET Framework anyway, it doesn't make sense for us to make this change.

github-actions[bot] commented 10 months ago

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

hashicorp / terraform-cdk