EventFlow assemblies are not strongly named
Closed this issue · 4 comments
Hello
When signing our application (See packages detail below), we realized, using the sn tool, that EventFlow assemblies were not strongly named since Microsoft.Diagnostics.EventFlow.Core 1.3.0
It could be related to this fix
The other EventFlow assemblies we’re using seem to be concerned too.
Could you have a look ? We are unable to sign our application.
We are using EventFlow (.net471) with these nuget packages :
Microsoft.Diagnostics.EventFlow.Core 1.5.7
Microsoft.Diagnostics.EventFlow.Inputs.Etw 1.4.1
Microsoft.Diagnostics.EventFlow.EtwUtilities 1.6.0
Microsoft.Diagnostics.EventFlow.ServiceFabric 1.5.0
Microsoft.Diagnostics.EventFlow.Outputs.ApplicationInsights 1.4.0
Regards.
@xenacaco correct, it was a deliberate decision not to strong name sign EventFlow assemblies.
Can you explain why you need to strong name sign your application?
This is part of our company’s policies, we want to make sure no fraudulent code is executed, so we need to strong name sign it.
We are surprised that Eventflow is not strong name signed, we never had this problem with other third party assemblies we use ?
The purpose of strong naming is to enable different versions of the same assembly to be loaded side-by-side and to enable storing the assembly in the Global Assembly Cache (GAC). It is not designed to ensure assembly publisher identity, nor ensure that the binary has not been tampered with https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming
Other technologies such as Authenticode and NuGet package signing are used to insure publisher identity and binary integrity. EventFlow NuGet packages are signed and the binaries inside them are Authenticode-signed.
The guidance for strong name signing has changed over last couple of years. It is now considered standard practice to put the strong name signing key into source code repository. This makes things easier for developers; to the point that we could re-consider having EventFlow assemblies strongly named in addition to being NuGet package-signed and Authenticode-signed. But the fact that the strong name key is available to everybody also reinforces the fact that strong naming is about assembly versioning/GAC, not security.
Closing this issue for now, but please let us know if you have further questions!