Saml2: Assembly signing

[grabmill]

It would be nice if the assemblies would be signed with some key. Some companies require all assemblies used to be signed. Although the project is open-souce, so we can always get the code and sign it ourselves, it would be nice if we could simply use the NuGet package for example and update it with 2 clicks if a new version comes.

[AndersAbel]

I understand your concern, but it's not an easy topic. The general trend within .NET open source projects is to not strong name/sign the assemblies as it makes it considerably harder to replace the AuthServices dlls used by an application without recompiling the rest of the application.

Actually, the possibility to replace the AuthServices version is a requirement by the LGPL license so the license implications would have be investigated before going down that path.

But first of all there must be considerable benefits of strong naming and I haven't found any yet. Some good links on the issue:

• http://www.outercurve.org/blog/2014/03/25/Strongnaming-I-Do-Not-Think-It-Means-What-You-Thin/
• https://github.com/dotnet/corefx/wiki/Strong-Naming
• https://json.codeplex.com/workitem/22458

What are the reasons for the policy to require assemblies to be signed? If it is for security reasons, that no longer applies (see the first link). If it is for the ability to have reference multiple versions of the same assembly I don't really see a use case for that for AuthServices.

If going with strong naming, I'd prefer to use the scheme adopted by JSON.NET and having the AssemblyVersion only contain the major version and put the complete version in AssemblyInformationVersionAttribute.

[grabmill]

Thanks a lot for this response. Indeed I wasn't aware of the fact that strong naming doesn't really add any security, so I might use that info to convince my customer to drop the requirement.

[k-soze]

Is it possible to sign the libraries because in some cases it is mandatory.
Can I suggest to create signed and unsigned libraires as output ?

[AndersAbel]

After this issue was closed, Microsoft has released new guidelines that suggest strong naming. See https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Reopening this issue and tagging it for the 3.X release as it requires thorough consideration on how to handle versioning.