fido2-net-lib

fido2-net-lib copied to clipboard

Hi, I wonder if it would please be possible to implement strong name signing of the assemblies. Assemblies from fido2-net-lib currently fail to load if an assembly referencing them is signed.

It is worth considering, however we would need to consider our dependencies since strong naming is viral.

And that users on .net framework might encounter binding issues.

I would like to await .net5 and see how the ecosystem develops. Any other thoughts?

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

IMO, having an entire app strong name signed adds some security to it. And fido2-net-lib is all about security, right? This viral strong naming is not a problem for fido2-net-lib, because all its current depencies are already signed (including JSON.NET, CBOR, and all libraries from Microsoft). I just checked.

The page you linked is definitely a good input for discussion. Issues with bindings can IMO easily be resolved using configs, should they occur. The doc also says the following:

The benefits of strong naming are:

• The assembly can be referenced and used by other strong-named assemblies.
• The assembly can be stored in the Global Assembly Cache (GAC).
• The assembly can be loaded side by side with other versions of the assembly. Side-by-side assembly loading is commonly required by applications with plug-in architectures.

Now that the library targets .NETcore only, I'm unsure any of the benefits of strong naming ^ are relevant. Microsoft has also provided guidance that strong naming SHOULD not be relied on for security.

I would recommend that we continue to keep the library unsigned and close this issue.

https://learn.microsoft.com/en-us/dotnet/standard/assembly/create-use-strong-named Do not rely on strong names for security. They provide a unique identity only.

Sure, for .NET Core / .NET 5, strong names generally do not make that much sense. My main motivation for this feature request was GAC (Active Directory Federation Services Extensions must be authored in .NET 4 and placed in GAC), but .NET Core no longer has the concept of GAC.