Strong name signing

[Kemyke]

We are using this great library in an environment where every package is signed. Currently we are signing this library during our build process. However it is currently fine but it would be great if you can sign the library. What do you think about this?

[canton7]

Sure, I'll look into it. I'll have to see if there are any implications or compatibility-breaking changes for other users: I know some libraries publish separate NuGet packages for signed / non-signed versions, for instance.

[roryprimrose]

It shouldn't be a breaking change unless you roll a signed package using a previous version and someone consumes one of its types using the fully qualified type name.

[canton7]

Looks like the issue quite a bit more complex than I'd anticipated:

• Strong naming an assembly messes with binding redirects in NuGet. The workaround seems to be to freeze the assembly version. People have referred to this as being a breaking change, requiring a separate NuGet package, but I'm not yet sure why.
• The 'dotnet' tooling doesn't support signing assembles. Apparently you can strong name assemblies without signing them, but I'm not sure of the distinction. Reference.
• Delay sign or not? Public sign or not?
• Commit the private key or not? Some projects seem to be committing it.

[chadly]

Please don't do this. Strong naming is the bane of my existence. I'd rather you just recommend Strong Namer for the people that really want it.

[Nick-Lucas]

+1 to using StrongNamer, I use this for WPF/ClickOnce deployments and it does the job great

[apopovsky]

Any updates on this?
We have the same problem. We want to use it in a project but a strong name is required.

[canton7]

The current status is that I've had 2 requests for strong naming (including yours), 1 request not to strong name, and a workaround proposed.

If you have experience with strong naming NuGet assemblies (which addresses the 4 points in my post above), and can contribute towards the effort, then I don't see the issue with releasing a second strong-named assembly...

[Nick-Lucas]

The simplest solution really is to use StrongNamer, it resolves the issue automatically with a build hook.

I know of very few NuGet libraries which are signed, and doing so has the potential to introduce its own issues.

[StefH]

StrongNaming is very easy, just follow these steps:

1] create a key sn -k RestEase.snk

2] edit csproj file, add these 2 lines in the element

    <AssemblyOriginatorKeyFile>RestEase.snk</AssemblyOriginatorKeyFile>
    <SignAssembly>true</SignAssembly>

3] In case you use InternalsVisibleTo, execute these:
sn -p RestEase.Net.snk public.key
sn -tp public.key

And copy the public key (only the numbers) into the InternalsVisibleTo like:

[assembly: InternalsVisibleTo("RestEase.Tests, PublicKey=002400.....97")]

If you want to see it working, take a look at https://github.com/StefH/System.Linq.Dynamic.Core/

[StefH]

@Nick-Lucas It seems that StrongNamer is not supported in dotnet (.net core projects)?

[lucaspimentel]

FWIW, the recommendation in non-Windows platforms was to "public sign" the assembly by adding <PublicSign> property to the project:

<AssemblyOriginatorKeyFile>RestEase.snk</AssemblyOriginatorKeyFile>
<SignAssembly>true</SignAssembly>
<PublicSign Condition=" '$(OS)' != 'Windows_NT' ">true</PublicSign>

From the C# compiler docs:

Sometimes called "fake sign" or "OSS sign", public signing includes the public key in an output assembly and sets the "signed" flag, but doesn't actually sign the assembly with a private key. This is useful for open source projects where people want to build assemblies which are compatible with the released "fully signed" assemblies, but don't have access to the private key used to sign the assemblies. Since almost no consumers actually need to check if the assembly is fully signed, these publicly built assemblies are useable in almost every scenario where the fully signed one would be used.

More details in the CoreFX repo. Also, this thread. Following that thread, however, TIL that signing is now supported cross-platform.

[justkao]

Please reconsider strong-naming this assembly. This issue has been discussed over and over again but recently Microsoft actually made a official statement recommending that all OSS nuget packages should be strong named.

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

As an alternative RestEase.Signed assembly can be produced as a side nuget package.

[canton7]

In fairness, that article does say

✔️ CONSIDER strong naming your library's assemblies.

And it also says:

❌ DO NOT publish strong-named and non-strong-named versions of your library. For example, Contoso.Api and Contoso.Api.StrongNamed.

Which I interpret as a weak recommendation to strong name, and a strong recommendation not to have both a strong-named and a non-strong-named version of the library.

The 4 points in my original question are still awaiting answers. If you have any input on those please provide it!

[justkao]

Sorry I can only provide the input about the 2th and 4hth question.

The 'dotnet' tooling doesn't support signing assembles. Apparently you can strong name assemblies without signing them, but I'm not sure of the distinction. Reference.

This is actually not true anymore, it's easy to sign the assemblies now using the new project system by using the <SignAssembly> tag.

Commit the private key or not? Some projects seem to be committing it.

The official recommendation is to commit the key into the source system.

[retailcoder]

This is OSS, the source code is right here, waiting to be forked. If you need strong naming, build it and strong-name it yourself - don't push your requirements and everything it entails onto 1) other users of the package, and 2) the maintainers of the package. I strongly oppose this proposal.

[Silvenga]

It should be noted that Strong Namer does not support net45, which RestEase does support, so recommending Strong Namer is an imperfect solution - along with all the other problems that Strong Namer has with new SDK projects.

I would propose looking at other open source projects, and how they strong name. Strong naming is an unfortunate requirement for many - even though some don't need it.

[StefH]

Hello @canton7, sorry to bother you about this issue. but do you have any update on this?

[canton7]

Same as last time:

The 4 points in my original question are still awaiting answers. If you have any input on those please provide it!

[StefH]

Strong naming an assembly messes with binding redirects in NuGet. The workaround seems to be to freeze the assembly version. People have referred to this as being a breaking change, requiring a separate NuGet package, but I'm not yet sure why.

I think you can just sign it. And if people or projects are having issues, you can always release a RestEase.Unsigned package.

---

The 'dotnet' tooling doesn't support signing assembles. Apparently you can strong name assemblies without signing them, but I'm not sure of the distinction.

I never had issues creating a signed NuGet.
See this #50 (comment)

---

Delay sign or not?
Public sign or not?

I do not delay the signing in my projects. I just sign it.

According to ChatGPT-4:

Delaying the signing of your NuGet package can have several reasons. Here are a few potential scenarios:

1. Testing: When a package is in the testing phase, you may want to keep it unsigned. This is because signing a package can be seen as a kind of finalization process. Before signing, developers may need to test and debug the package, and any changes made after signing would require the package to be re-signed.
2. Security Concerns: If you are worried about the security of your private key, you might delay signing the package until you are sure your key is secure and won't be compromised.
3. Versioning Control: If you are still working on your package and expecting to update the version soon, you may want to wait until the final version is ready before you sign it.
4. Infrastructure Constraints: In some cases, developers might not have immediate access to their certificate's private key needed for signing, especially in distributed teams or strict security contexts. Therefore, they could decide to delay the signing process until they can secure the necessary resources.
5. Dependency Management: If your NuGet package has dependencies that aren't signed or are being updated regularly, you might want to delay signing your package until those dependencies are stable and signed.

---

Commit the private key or not? Some projects seem to be committing it.

I do commit it, but if you are really are concerned that other people/projects can use your key and use it for other projects, then you should keep it outside of source-control

---

I hope I did clarify some questions.

[Silvenga]

That's where Chat-GPT is wrong. Strong signing shouldn't be used for security (it's too weak, and there lacks needed verification checks), code signing should be - which doesn't modify the assembly identity.

The point of strong signing is to increase the uniqueness of the assembly identity - the most common reason, is if installing the assembly into the GAC.

Really, strong signing is an artifact of .NET Framework - and security researchers that don't look deeper than the name.