Akka.net: Signing nugget package

[sonicflare]

Can you add strong name to nuget release?
Projects that has been already signed, cannot reference unsigned assemblies.

[rogeralsing]

I know that Polly https://github.com/michael-wolfenden/Polly uses double nuget packages.
Polly + PollySigned.

Not sure how I feel about that but it would be doable.

[sonicflare]

Do you really need signed and unsigned?
Unsigned projects can reference signed assemblies without any problems.

[Aaronontheweb]

I thought this discussion about the same issue for Octokit was actually pretty informative:

https://github.com/octokit/octokit.net/issues/405

[Aaronontheweb]

My personal opinion: it's a pain in the ass and there aren't strong benefits for doing it other than "I need it"

Worst case scenario: users who need it can clone the repo and do a local build and strong-name it themselves.

HOWEEEEEEEEEEVER.

What I would like to know is - how many people actually do need it? I imagine Akka.NET is a lot closer to something enterprises need than Octokit, and I want to be sensitive to that. But strong-naming comes at a steep cost for everyone else who doesn't need it.

[rogeralsing]

If we play our cards right, this could be more epic than async await.

@kekekeks + @nvivo whats your oppinions on this topic? :D

[sonicflare]

People can go and compile the source with or without the strong name, if they wish so.
The problem comes with dependency mechanism. aka nuget. Nuget does allow only one type of dependency, and I think it would be better to go bug nuget guys to add a flag for signed/unsigned.

[nvivo]

Yeah, this signed dependency is a pain. Honestly, I have mixed feelings about it, but I'd favor giving people a signed assembly somehow, even if that means polluting nuget with 2 packages of each. IMO, adoption is more important than preferences at this point.

Things change all the time, if you're not too religious about that, I'd vote for having alternative "*-Signed" packages and see how many people use that. At some point if that is worth it and don't hurt anyone, just make everything signed.

[nvivo]

BTW, thanks for including me just to see if I could help to start a fight. That's a lot of consideration. I'll remember that Roger. =)

[kekekeks]

I don't see why we can't just sign it and include strong-naming key in the repo. Build process won't be broken anywhere and those "I WANT STRONG NAEMD ASSEMBLY!!!111" guys will be happy.

For "some library I'm using has referenced an earlier version of Akka" issues there is binding redirect which is added to app.config/web.config automatically by NuGet.

[kekekeks]

And that "freeze assembly version number approach" from octokit discussion fits nicely with this.

[Danthar]

I don't have a strong opinion on this issue. But if we are going strong name: I vote for only having 1 nuget package, and freezing the assembly version number.

Although I really think that SN as it is now will change in the future.

[Aaronontheweb]

I'm almost positive that strong naming as we know it is going to be deprecated in the near future.

That being said, I want to support our fellow homies who have strong naming needs.

I'd like to propose that we offer a separate nuget packages with strong naming support. Seems to be what RestSharp and other large libraries are doing. We can add this to our build process.

[kekekeks]

The problem with 2 packages is that at some point one might try to use a library that is strong named and referenced signed Akka and another library that isn't strong named and referenced unsigned Akka. Welcome to DLL Hell.

[stefansedich]

I think that library just needs both options too. Signing is a legacy IMO
and I dont want to see us putting too much effort into it, hell async is
bad enough

My 3.5c
On 9 May 2015 6:16 pm, "Nikita Tsukanov" [email protected] wrote:

The problem with 2 packages is that at some point one might try to use a
library that is strong named and referenced signed Akka and another library
that isn't strong named and referenced unsigned Akka. Welcome to DLL Hell.

—
Reply to this email directly or view it on GitHub
https://github.com/akkadotnet/akka.net/issues/957#issuecomment-100446920
.

[takemyoxygen]

No decision made so far?
I'm one of those "enterprise" devs who has to use signed assemblies. If there's no chance that signed version of the package will be added, we'll probably build and sign it locally ourselves.

[christopherbahr]

Another +1 from a dev who needs to use signed assemblies.

[mithril52]

+1 for needing signed assemblies

[OlegZee]

We have a system which purpose it to run some custom code in isolated application domains with strictly limited permissions. That medium trust machinery heavily relies on strongly named assemblies.

Just my +1.

[wtulloch]

Having wrestled with this for the good part of the day I would also like see signed assemblies. There are a couple of tools out there let you sign an assembly after the fact which works up to a point but in my case failed because Akka.Logger.Serilog was still trying to load the unsigned version of Akka.dll (as an aside Serilog is strongly-named).

I also went done the path of cloning the source and signing it but then this failed when using clustering because of the dependency on Helios (which is unsigned).

[vacuumstate]

I've pondered this question over the years, and am now choosing the path of least resistance i.e. unsigned assemblies; - many mainstream/popular NuGet packages are released unsigned nowadays.

From the following info (unverified) it looks as if the tamper-proofing aspect is no longer the case anyway looking at this link

For edge-case scenarios, signing after the fact is always available if the assemblies have to be signed.

[JeffCyr]

I think people agreed that strong naming was to be used for unique identity and not security.

However, the "Strong-Name Bypass" can be disabled by a registry setting.
https://msdn.microsoft.com/en-us/library/cc713694(v=vs.110).aspx

[vensa-emonzon]

Any decision on this? I am also working on a project where I need to use signed assemblies. I will be cloning the Akka.NET repository and signing it myself to use it on my project for the time being, but it would be nice if we can get a signed Akka.NET NuGet package.

[PowerMogli]

+1 for needing signed assemblies. We need to use signed assemblies in our projects.
We also need Akka.TestKit as a signed assembly. Otherwise we cannot write unit tests for our actors.

As long as there are no signed assemblies we have to do it by ourselves :(

[gravufo]

+1. We are spending hours at work trying to automate the signing process for your NuGet packages, but it's a pain in the ass due to the InternalsVisibleTo tags in your DLLs! Please enable strong-name signing. It doesn't affect people who don't strong-name their projects, but it will save LOADS of time to all the people that do. Consider that lots of enterprises use this library and most of them probably use strong-name signed software due to client requirements.

[marcpiechura]

Would this maybe help?

https://github.com/dsplaisted/strongnamer

[gravufo]

Doesn't help. Akka DLLs are shipped separately in different NuGet packages but they have "InternalsVisibleTo" tags in their DLLs for other DLLs that are not in the same package. Tools like the one you linked will simply remove these tags if the reference is not found which would possibly break functionality.

I was looking on a way to automate this step, but it seems very difficult due to that reason.

Thanks for the input though!

[sergey-litvinov]

@gravufo Based from StrongNamer source code it uses Mono.Cecil and it actually does InternalsVisibleTo changes. So if you specify KeyFile and list of assemblies, it should sign each of them and also process their metadata to fix InternalsVisibleTo attributes. I didn't use StrongNamer, but i did similar thing with Mono.Cecil and it works great.

[ErrCode]

I had success with BrutalDev StrongNameSigner Nuget, where the tool runs over the Akka.Net dll's as a pre-build step in one of my projects like so:
StrongNameSigner.Console.exe -in ".\Nuget\Akka.1.2.0\|.\Nuget\Akka.TestKit.1.2.0\|.\Nuget\Akka.TestKit.NUnit3.1.1.2\|.\Nuget\Akka.TestKit.VsTest.1.1.1\ "

Notes:

• There is a space before the last ". Seems like BrutalDev StrongNameSigner (using the latest v2.1.0) might have a bug, but if I didn't have that space there it would think that " was part of the directory path and would say it couldn't find the folder of .\Nuget\Akka.TestKit.VsTest.1.1.1".
• I tried Silv3rcircl3's suggestion of StrongNamer before this, but had issues. Although it all seems to compile fine, my VS2015 IDE was unable to discover the tests for any of my test classes that extended TestKit (tested TestKit.NUnit3 and TestKit.VsTest).

Anyway. Hope this helps someone else!

[Danthar]

There are 2 options available atm.
1: You sign them yourself using StrongNamer or whatever you want.
2: You get a Petabridge license that includes official support and also includes signed libraries (AFAIK)

We as the OSS project are not going strong name our stuff.

[Aaronontheweb]

So, looks like JSON.NET is going down the route of being strong-named only since it's being taken as a dependency in ASP.NET Core, ditto potentially with Polly:

https://github.com/aspnet/HttpClientFactory/issues/105#issuecomment-385527782

Given that strong-naming has a bit of a viral effect, we might eventually have to go down that road too. Good lord, I hope not.

Gitter is down at the moment otherwise I would have raised this there, but the specter of having to strong-name Akka.NET appears to be raising its head again.

My $0.02 is that it's a stupid pain in the ass and offers zero security benefits but since corporate IT departments, many of whom are our users, demand it and aren't going to be changing that position any time soon, we might need to support it.

I'm just going to follow the conversation on the issue I've opened there, but I'd love to hear from our actual end-users how this might positively or negatively affect them.

[joelhulen]

@Aaronontheweb Sorry, it seems like we've opened a big can of worms. I never liked having two separate packages, one signed and the other not. That decision was made before my time. I also don't like having to have any signed version, but reality dictates that it's necessary for the reasons you already stated. It's now more important than ever since Polly is now being distributed with ASP.NET Core 2.1, which uses strong-naming.

I'm definitely interested in hearing some good ideas on how best to approach this, within the issue you referenced, the issue on our Polly repo, and within this issue. Hopefully our collective heads will come up with the best approach moving forward.

[iancooper]

@Aaronontheweb I'm sympathetic as it looks like we are going to have to take the pain on this as well. The continued use of strong-naming in MS assemblies is now the issue, because we want them to use community projects like Polly, and to do that we are going to have to accept they will strong-name. The downsides to that are that the ecosystem needs to react to that signing, but also more pressure on us all to cave and strong name too. Yes, it has zero real benefits, and is theater but we seem to have few choices that work.

[Aaronontheweb]

@iancooper @joelhulen

My reading of the tea leaves is thus:

1. Virtually all of Akka.NET's dependencies are going to be strong-named at this rate: JSON.NET, DotNetty (produced by MSFT,) System.Collections.Immutable... If Google gets onboard and strong-names Google.Protobuf by default then the train has left the station :p
2. Once that happens, a lot of the benefits of not strong naming our project are significantly diminished already; due to diamond dependencies on things like JSON.NET, if our users want to use ASP.NET Core 2.x with Akka.NET 1.x, we're going to need to be aligned on at least the major versions of all of these dependencies since binding redirects will no longer be viable.
3. If Microsoft is seriously considering finally, FINALLY not NIH-ing everything the third-party .NET ecosystem has spent years developing out in the open and actually using that technology inside their own then it's a huge win for everyone. Will Microsoft finally consider adopting Reactive.Streams instead of inventing some IAsyncEnumerable mutant? Awesome! But if strong-naming is part of the price of admission, that totally changes the calculus for us.
4. Lastly, if due to points 1 and 2 we've already lost a lot of the benefits of not strong-naming then the people who have been demanding that we strong-name our own assemblies might actually have the stronger of the two arguments, I'm sorry to say.

I might be wrong about points 2 and 4 and I'd like that to be the case, but this is part of the viral nature of strong naming. All you need are enough 800lb gorillas in the your userbase demanding it as a condition of their adoption and some bigger libraries like JSON.NET caving to have it snowball.

Strong naming completely breaks some of the flexibility in the .NET ecosystem as a whole; binding redirects are not an anti-pattern. They are a necessity that allows open source software to be released independently, by different maintainers, and at different release rates.

In my opinion makes diamond dependencies a much more severe threat the project independence and stability over the long-term and will ultimately harm the ecosystem. If Microsoft wanted to do the brave thing, it'd be to very publicly kill off strong-naming altogether.

[Aaronontheweb]

In all honesty though, we're probably not going to need to strong-name still: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md - doesn't seem like we're at a use-case yet where it's merited.

I reopened the issue because, like I mentioned above, the calculus for doing it might be changing. Even if we have to do things like synchronize on the major versions of Newtonsoft.Json in order to play nice with ASP.NET Core, that doesn't mean we need to go all-in on strong naming ourselves.

Rather than take any action right now, I'd like to keep the issue open to see what users and the other members of @akkadotnet/core think on the subject.

[Danthar]

very publicly kill off strong-naming altogether

I think that would be the best move for the entire platform. Maybe im living in a bubble, but i have never found any advantage to SN.

[gravufo]

I don't think you understand what it means to have clients that have stupid requirements that we need to satisfy to stay in business. We all know strong naming is pretty much useless and is a pain in the ass, but there's not much we can do.

[Aaronontheweb]

I don't think you understand what it means to have clients that have stupid requirements that we need to satisfy to stay in business

We do, hence why I reopened the issue.

[gravufo]

My comment wasn't targeting you, but indeed, thanks for reopening.

[cptjazz]

Is there any news on this issue?

Microsoft's recommendation for _libraries_ is to apply strong name signing: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming.

I (as several commenters before me) am bringing this topic up because on the project at work where we want to use Akka we are required to strong name the assemblies. What I do not understand is why there should be a need for two package families, signed and unsigned. This does not really make sense to me because every assembly can consume signed assemblies but not vice versa.

If possible (w. r. t. the dependencies) I would suggest to consider strong naming all Akka assemblies.

I desired, I can offer my help on this topic, e. g. checking if (and which) dependencies are making problems (are not strong name signed).