Add Strong name

[ndrwrbgs]

Fixes #23

[codecov]

Codecov Report

Merging #48 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #48   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           5      5           
  Lines         229    229           
  Branches        7      7           
=====================================
  Hits          229    229

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b9ca357...b56c914. Read the comment docs.

[JSkimming]

@ndrwrbgs I'm open to being persuaded to sign the assembly, I want to check if we "really really" need this.

After a little research, I found this documentation.

For the most part, the majority of applications and libraries do not need strong-names. Strong-names are left over from previous eras of .NET where sandboxing needed to differentiate between code that was trusted, versus code that was untrusted. However in recent years, sandboxing via AppDomains, especially to isolate ASP.NET web applications, is no longer guaranteed and is not recommended.

It sounds like strong naming provides little benefit. The next point in the link document goes into the potential issues of strong naming,

1. Binding Policy. When developers talk about strong-names, they are usually conflating it with the strict binding policy of the .NET Framework that kicks in when you strong-name. This binding policy is problematic because it forces, by default, an exact match between reference and version, and requires developers to author complex binding redirects when they don't. In recent versions of Visual Studio, however, we've added Automatic Binding Redirection as an attempt to reduce pain of this policy on developers. On top of this, all newer platforms, including Silverlight, WinRT-based platforms (Phone and Store), .NET Native and ASP.NET 5 this policy has been loosened, allowing later versions of an assembly to satisfy earlier references, thereby completely removing the need to ever write binding redirects on those platforms.

2. Virality. Once you've strong-named an assembly, you can only statically reference other strong-named assemblies.

3. No drop-in replacement. This is a problem for open source libraries where the strong-name private key is not checked into the repository. This means that developers are unable to build to their own version of the library and then use it as a drop-in replacement without recompiling all consuming libraries up stack to pick up the new identity. This is extremely problematic for libraries, such as Json.NET, which have large incoming dependencies. Firstly, we would recommend that these open source projects check-in their private key (remember, strong-names are used for identity, and not for security). Failing that, however, we've introduced a new concept called Public Signing that enables developers to build drop-in replacements without needing access to the strong-name private key. This is the mechanism that .NET Core libraries use by default.

[JSkimming]

Is this still needed? It looks signing is supported on CoreCLR

dotnet/roslyn#8210

[ndrwrbgs]

Fortunately, this library only depends on other strong named assemblies, so that’s not a problem. #2 is why I believe we should strong name - we have consumers who (for whatever reason) have to be strong named and as such can’t rely on this without it also being strong named. (I myself am now one of such consumers :) ) Yes, it’s a pain and the whole world should get rid of strong naming I feel :). But if we don’t strong name here then folks will have to do more work on their end. For folks who aren’t bothered by such things, consuming a strong named assembly won’t be a problem for them (it’s only the other way that has issues). Ethically, I must comment that #1 can be a problem - binding redirects are already going to be imposed on users of this library because it uses Castle, who is strong named, but I’ve discovered that right at the switch to strong named binding redirects are particularly hard or impossible. This would only be a problem for transitive dependency scenarios - consumers of consumers of this library would really need the direct consumers to update.

…

On Sun, Aug 5, 2018 at 11:53 PM James Skimming ***@***.***> wrote: ***@***.**** commented on this pull request. @ndrwrbgs <https://github.com/ndrwrbgs> I'm open to being persuaded to sign the assembly, I want to check if we "really really" need this. After a little research, I found this documentation <https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md#1-microsoft-strong-names-their-assemblies-should-i> . *For the most part, the majority of applications and libraries do not need strong-names. Strong-names are left over from previous eras of .NET where sandboxing needed to differentiate between code that was trusted, versus code that was untrusted. However in recent years, sandboxing via AppDomains, especially to isolate ASP.NET <http://ASP.NET> web applications, is no longer guaranteed and is not recommended.* It sounds like strong naming provides little benefit. The next point in the link document goes into the potential issues of strong naming, 1. *Binding Policy*. When developers talk about strong-names, they are usually conflating it with the strict binding policy of the .NET Framework that kicks in *when* you strong-name. This binding policy is problematic because it forces, by default, an exact match between reference and version, and requires developers to author complex binding redirects <http://msdn.microsoft.com/en-us/library/eftw1fys.aspx> when they don't. In recent versions of Visual Studio, however, we've added Automatic Binding Redirection <http://msdn.microsoft.com/en-us/library/2fc472t2.aspx> as an attempt to reduce pain of this policy on developers. On top of this, all newer platforms, including *Silverlight*, *WinRT-based platforms* (Phone and Store), *.NET Native* and *ASP.NET <http://ASP.NET> 5* this policy has been loosened, allowing later versions of an assembly to satisfy earlier references, thereby completely removing the need to ever write binding redirects on those platforms. 2. *Virality*. Once you've strong-named an assembly, you can only statically reference other strong-named assemblies. 3. *No drop-in replacement*. This is a problem for open source libraries where the strong-name private key is not checked into the repository. This means that developers are unable to build to their own version of the library and then use it as a drop-in replacement without recompiling *all* consuming libraries up stack to pick up the new identity. This is extremely problematic for libraries, such as Json.NET, which have large incoming dependencies. Firstly, we would recommend that these open source projects check-in their private key (remember, strong-names are used for identity, and not for security <http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx>). Failing that, however, we've introduced a new concept called Public Signing <http://public-signing.md> that enables developers to build drop-in replacements without needing access to the strong-name private key. This is the mechanism that .NET Core libraries use by default. ------------------------------ In src/Castle.Core.AsyncInterceptor/Castle.Core.AsyncInterceptor.csproj <#48 (comment)> : > @@ -17,6 +17,14 @@ <RepositoryType>git</RepositoryType> <PackageTags>async asynchronous-methods castle castle-core dynamic dynamicproxy dynamic-proxy dynamicproxy2 intercept-methods proxy</PackageTags> </PropertyGroup> + + <!-- Strong name signing --> + <PropertyGroup> + <SignAssembly>true</SignAssembly> + <AssemblyOriginatorKeyFile>$(MSBuildThisFileDirectory)SharedKey.snk</AssemblyOriginatorKeyFile> + <!-- Explanation for the condition https://github.com/dotnet/cli/issues/6911#issuecomment-309647478 and https://github.com/dotnet/cli/issues/6911#issuecomment-310099022 --> + <PublicSign Condition=" '$(OS)' != 'Windows_NT' ">true</PublicSign> Is this still needed? It looks signing is supported on CoreCLR dotnet/roslyn#8210 <dotnet/roslyn#8210> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKRxOnLjTCI87fND15bOud-5fdCdynAOks5uN-fQgaJpZM4VvGUO> .

[JSkimming]

Ok