SNK signing the DLLs in the NuGet package (.NET)

[Thomas Speckert]

Hello,

Would it be possible to have the two assemblies in the NuGet package (DNP3CLRAdapter.dll and DNP3CLRInterface.dll) signed with a strong name key? This is important in .NET, since you can't reference (well, easily anyways :) ) a non-signed assembly from within a signed assembly.


Thanks,
Thomas

[J Adam Crain]

I don't have any experience doing this, but if it's something we can automate (i.e. safely install our private key) on AppVeyor, I'm open to the idea.

The appveyor project is here:

https://ci.appveyor.com/project/jadamcrain/dnp3

and the config here:

https://github.com/automatak/dnp3/blob/2.0.x/appveyor.yml

Sid Hoda put 99% of this together for us.

-Adam

[Thomas Speckert]

So I dug around, and came up with two ways to signing can be handled:

1. Don't care at all about security and simply generate a completely unencrypted pub/priv key pair (.snk file), and store that in source control. A lot of open source projects seem to handle it this way; I guess because a) signed assemblies don't do much on their own since public keys aren't typically stored with a trusted CA, and b) if someone really cares about security, they could simply build everything on their own supplying their own private key. Some examples of this are here, here and here (starting with v5).

2. Generate a key pair that is encrypted (can be done in VS) and store the encrypted key in the repository. Include a program in your project that converts the pfx file to a snk file (see PfxToSnk in the sample project - adapted from here). Configure the projects to use the unencrypted key, but don't include the unencrypted key in revision control. With appveyor, you can provide the password as an environemnt variable in the project settings (which is not logged), so the encrypted key is decrypted at build time. I made a proof of concept here: https://github.com/tspeckert/signtest NOTE: anyone building the project on their own will have to provide their own key, or disable signing.

Option 2 is a bit more convoluted than I'd like since MS's sn.exe program doesn't let you pass in the password via stdin or via an argument unfortunately.

Regards,
Thomas

PS. Sorry if this is a bit unclear, I wrote this in a rush as I had to leave