Conversation
… public on github, its privacy or origins are inconsequential
Codecov Report
@@ Coverage Diff @@
## master #48 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 5 5
Lines 229 229
Branches 7 7
=====================================
Hits 229 229Continue to review full report at Codecov.
|
JSkimming
left a comment
There was a problem hiding this comment.
@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,
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.
Virality. Once you've strong-named an assembly, you can only statically reference other strong-named assemblies.
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.
| <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> |
There was a problem hiding this comment.
Is this still needed? It looks signing is supported on CoreCLR
|
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>
.
|
Fixes #23