Strong Naming the Library

[linvi]

Hello,

The current version of the library retrieved from nuget (1.1.0) is not strong named (dotnet standard version).

sn -vf .\Nito.AsyncEx.Context.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

.\Nito.AsyncEx.Context.dll does not represent a strongly named assembly

Are you planning on strong naming this library at any point?

Thanks,
Linvi

[StephenCleary]

There are no plans to have AsyncEx support strong-naming directly.

Eventually, I plan to provide a strong-naming NuGet service, so any NuGet package can be strong-named. This is an "eventually" that is in line behind many other major projects, though, so realistically we're probably talking several years out.

[linvi]

Is there any good reason to not support strong naming?
I mean, I will create a nuget Nito.AsyncEx package with Strong Naming, but why don't you want to support this by default?

[linvi]

Anyway, if someone needs a StrongName version of the library I just uploaded it on nuget :

https://www.nuget.org/packages/NitoAsyncEx.Context.StrongName/

Cheers,
Linvi

[colgreen]

Microsoft guidance for open source packages is to strong name and publish the private key!

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

[StephenCleary]

They don't have to put up with the pain of maintaining a strong-named library.

[colgreen]

I've noticed that this situation seems to come up reasonably often on different projects. We (my colleagues and I) had this same discussion with the Math.Net maintainer, and the end result was to switch to publishing a single nuget with strong named assemblies, i.e. AFAIK those should work everywhere. I would be interested to know if that approach also has problems.

Either way, thanks for these packages.

[StephenCleary]

The problem is not publishing a strong-named package; that's trivial. The problem is dealing with all the end-user issues that come from having strong-named dlls inside a semantically-versioned package.

Even in the most trivial cases, you need binding redirects. Which - we are constantly told - the tooling will magically handle for us. But in the Real World, that never works out; the tooling often gets it wrong, terribly wrong. And binding redirect issues aren't easy for most developers to know how to resolve. IIRC there's also problems with diamond dependencies across multiple versions, but all using the same dll filename.

The standard approach to these from a library perspective is to strong-name only major versions. E.g., AsyncEx v3.0 and v3.1 will both be strong-named as v3.0.0.0. So the version in the dll is major-only to prevent mitigate these strong-naming issues. That's the only really viable approach. One downside is that the dll versions no longer match the package versions, so you can't look in your bin directory and see what version you're on; I think the best workaround for that is to include the package version as the dll's "informational version", which isn't used in strong-name matching. The other downside is that you have to script all of this somehow in your own build scripts, because there's no tooling support for doing strong-naming this way.

To summarize: strong-name support is more involved than Microsoft likes to claim. It's not just clicking a checkbox or two and rebuilding. I've seen a lot of projects adopt strong-naming, and then drop it again after a major update or two, just because of the cost of dealing with end-user issues. I'm very interested in seeing what happens after a couple major versions of Math.Net.

That's not to say I'm 100% against strong-naming; there are a few places where it's downright required. (Which IMO is a defect in the platform, but regardless...) An interesting side effect of how strong-naming works is that it can be automated. E.g., the Assembly Strong Naming Toolkit or StrongNameSigner. What I'd like to see is a web service that will do this for any given NuGet package and then publish that package. This is on my list of things to do. Someday, when I have time. Which probably means never. That whole project is up for grabs! ;)

[markusschaber]

Thanks for the detailed explanation of your motivation!

[jzabroski]

Basically, strong naming is really dumb when you come from a Linux background and grew up building your own Operating System with gcc from debian package sources.

All that matters is that the keyring is protected and the ring of package maintainers does not break the ring of trust. You can then daisy chain authorization of a package through keyring signing. This creates a form of distributed consensus on package naming.

What would be even better - and deeper - is proof-carrying code that does structurally signing of each faceted interface. Effectively, the same way that C# dll's can be marked as CLI Compliant, you want your code to be marked as not changing from semver to semver. That would fully materialize the semver such that you can automatically roll-up changing behaviors. However, in the general case, of a plug-and-play system, there is effectively no code to authenticate, because everything is zero trust and can be swapped in at any time. This would bring us "Halfway to cfengine" in terms of thinking about component upgrades as a 3-SAT solving problem, which is why managing software dependencies is so complex - it's deeply mathematically complex.

Small rant.

[StephenCleary]

Important side note: "strong naming", in spite of using a "key", provides absolutely no security. Because these keys aren't trusted at all (by software). After many years, Microsoft finally added this to their docs:

Do not rely on strong names for security. They provide a unique identity only.

Strong-named assemblies literally just provide a guarantee that they haven't changed since the last time they were changed. Seriously. The tools I referenced above are capable of removing a strong-name from an assembly, modifying it, and then applying a (new) strong-name to that assembly. The new assembly is perfectly valid as a strong-named assembly.

Which really means that strong naming is useful in two - and only two - use cases:

1. You want to load multiple versions of the assembly into your app.
2. You need to run on a platform that (stupidly) requires strong-name signing. I say "stupidly" because there is no reason for a platform to require this.

[jzabroski]

@StephenCleary You may find Nate McMaster's DotNetCorePlugins project v. interesting, as well as his blog post about it: https://natemcmaster.com/blog/2018/07/25/netcore-plugins/ - it gets us once step closer to OSGi and Maven/Ivy style dependency management.