search

etishor / Metrics.NET

The Metrics.NET library provides a way of instrumenting applications with custom metrics (timers, histograms, counters etc) that can be reported in various ways and can provide insights on what is happening inside a running application.
Apache License 2.0
647 stars 150 forks source link

Nuget packages with strong names #91

Open duszynski opened 9 years ago

duszynski commented 9 years ago

Can you update nuget packages with signed versions?

etishor commented 9 years ago

I have not used strong named assemblies in the last years. I'm not against them, but I know they are known to cause trouble. I'll take a look on how popular projects handle this and see if it is possible. The core library has (and will never have) any 3rd party external dependencies - so it should be easy to have it signed. Adapters on the other hand have dependencies which are probably not signed (like Nancy).

Can you provide more details on how strong named packages would be helpful?

duszynski commented 9 years ago

Security reasons. I was trying to use it in healthcare project, but app must be signed.

etishor commented 9 years ago

Here is a link to the strong naming policy and reasons for the .net corefx libraries. The general idea is to sign core framework libraries for compatibility and not to sign open source, general purpose libraries to avoid issues with dependencies and to have the "drop-in" replacement possibility.

Strong naming does not give you any security. It gives you guarantees of identity of the signed assembly.

That being said I see two options:

  1. publish a .nuget package under a different name (Metrics.NET-Signed) with a signed version of the library with the key included in the repository for posterity.
  2. sign the assembly yourself using something like Nivot.StrongNaming - an example with signing NancyFX here.

Since I personally don't use strong naming and don't foresee ever using it, I don't want to take responsibility of maintaining a strong named package - but it should be easy for anyone to clone the repo and publish the signed package.

I would recommend using option 2 because of the benefit of being able to sign it with your own key (thus getting some "security" as the assembly can't be replaced).