Signed nuget packages

[idursun]

Are there any plans around publishing signed NuGet packages as well?

Right now, it is not possible to reference packages in a signed project.

[cpx86]

Makes sense to do, so I guess now there is 😄

[adamhathcock]

Use this instead https://github.com/dsplaisted/strongnamer

[idursun]

@adamhathcock I have tried that something similar (i.e. strongnamesigner). It works but slows down the build process.

Some other libraries publish signed ones with StrongName suffix. Thought that might be convenient to do.

[adamhathcock]

It may slow your build but strong naming is your problem. You're making the decision.

Making it easy for you is putting the burden on this project to make strong naming work.

I'm quite opinionated about strong naming :)

[idursun]

Yes, I can see that. I am not a fan of signing as well.

The problem I am facing here is that it's company policy to sign everything we release.

I want to use proto.actor as it is a great fit for our product but telling the team that "in order to use it you have to reference this strongnamer in our project and on the top of that you will have slower builds from now on" doesn't really sell.

Everybody can be strongly opinionated about everything and it doesn't really solve any problem in the end.

[adamhathcock]

Why does every developer have to use it? There is documentation on how to disable it by default then make the build server do it.

Surely, all devs aren't strong naming locally all the time.

Proto Actor has a number of libraries with different dependencies. Some may not be strong named.

I guess it's not my call but I still want to push back on any strong namer and make it their issue.

[adamhathcock]

I might play with strong namer and Cake soon. Doing it as a pure build step is interesting even if I consider strong naming a sin :)

[cpx86]

Personally I can very much sympathize with battling long CI build times, so if we can solve this in a way that doesn't put a heavy burden on us then we should try and go for it. That said, I don't have a lot of experience with signing assemblies (sounds like I'm lucky!) 😄

[rogeralsing]

What is the current state of signed packages in .NET land?

[raskolnikoov]

https://docs.microsoft.com/en-us/nuget/reference/signed-packages-reference

Great!

[rogeralsing]

Dafuq, we need certificates nowadays?

[alexeyzimarev]

I think there's a misunderstanding here.

The issue reporter probably needs strong naming, not package signing. Strong naming ensures that the referenced assembly is matched by key also, not just by name.

It has little to nothing to do with nuget package signing.

Nowadays it is safe to assume that publishing signed assemblies only is safe. I did it with RestSharp and never got any complaints. Before, we have one package for signed assemblies and one for unsigned. It's not needed today.

Basically, all it boils down to is:

• Get a snk file
• Add two lines to csproj (now into the Directory.build.props) file

    <AssemblyOriginatorKeyFile>..\..\Whatever.snk</AssemblyOriginatorKeyFile>
    <SignAssembly>true</SignAssembly>

[alexeyzimarev]

But it creates madness around InternalsVisibleTo, which requires the private key to be specified. And all test projects need to be strong named too. Plus, Marten and Wire aren't strong named, so those libs must be excluded. I am not sure tbh.

[cpx86]

Well the Marten/Wire projects should be moved to another repo anyway - perhaps we can leave all the contrib packages without strong names?

[alexeyzimarev]

I think so, I also got in trouble referencing the snk file from directory build props. I tried using MS Build csproj var to refer to the repo root but it only works with CLI build and Rider fails to build, for example. If we won't have subdirectories in src - it would be easier.

[alexeyzimarev]

Ok, the move to contrib is done, now we need an snk file. Never done it before tbh.

[alexeyzimarev]

Is anyone interested in that now? I made the PR but it seems to get no traction.

[rogeralsing]

Let's clean up the PR and resolve this one