Sign the aether assemblies with a strong name
codasols opened this issue · 9 comments
Have you considered signing your assemblies with a strong name?
The problem with not signing your assemblies is that you alienate the inclusion of your library in a project that is strongly named. I can get around this temporarily, but I have to actually sign your dlls with my own key. This is a bit of a hassle, especially if I want to release my work as an open source project.
Hi @ptcoda - the short and honest answer is no I hadn't considered it 😄 - mainly because nobody has asked before! My impression had been that in general people had moved away from signing libraries (it's not something I've ever done) but I'm definitely willing to admit that I'm not an expert on the issues around it. I'll do a bit of background reading on it. If it can be non-disruptive and potentially just integrated in to the CI process, then i'm happy to do it if it's useful.
(If you've got any advice on the best way to do it, feel free to let me know too!)
I still believe there is value in signing assemblies, as it ensures the identity of your work (definitely not something that should be used for security purposes). Plus the added benefit of allowing your work to be used by everyone (both in open source and enterprise). Having an unsigned assembly is more restrictive.
I have noticed that you are building this project with Appveyor. The good news is that they provide you with the tools for handling private keys quite easily (I am doing this currently on a project that I have just started)
- Generate your signing key by opening up a Visual Studio Command Prompt and then using the Strong Name tool, generate a private key as follows:
sn -k Aether.snk - With an F# project you will need to modify the AssemblyInfo.fs file to include a reference to the key. This reference is relative to the location of the fsproj file:
[<assembly: AssemblyKeyFileAttribute("../keys/Aether.snk")>] - As you will know, a private key should not be stored within your source control. So to get around this, appveyor has a Nuget package called secure-file. This allows you to encrypt the key with Rijandael encryption. The output, typically a .enc file should be stored in source control.
secure-file -encrypt Aether.snk -secret <passphrase> - Your passphrase needs to be added to your appveyor.yml file as a secure environment variable. Doing this is pretty straightforward, and is done directly on your project page. Follow this link for further instructions.
- To get Appveyor to use this key. You need to customise your build script (or the appveyor.yml directly), to decrypt your key with your chosen passphrase. This key should be in the expected location, as defined within the AssemblyInfo.fs file in step 2:
secure-file -decrypt Aether.snk.enc -secret <passphrase>
If you need some further context, please have a look at my github project. It is not on the master branch, and is still a work in progress.
Hope this helps.
Thanks for the detailed feedback! I'll have a look into that and see how straightforward it would be to make my standard build work with that.
(There is another part of me which is beginning to remember some of the reasons i've never engaged with the process in the past though, often due to situations like this: https://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/ . What's the goal of signing/strong naming for you, with your assemblies? I'm interested in what you gain from it!)
Thanks for posting that link, was a good article to read. I will be honest, I never realised how controversial strong naming appears to be. My reasons for strong naming, is probably a little naive. I prefer to strong name, so that my assemblies are available to everyone. I guess it depends on what type of assembly you are creating, about whether it needs to be signed. I didn't quite realise the pain people experienced with binding redirects and strong named assemblies. I will have to say, that I must have been lucky, because I personally have never experienced it.
I guess the strategy by Newtonsoft Json is the best for signed assemblies and that is to lock down the version on the DLL and up version within Nuget only.
I will leave the decision to you. After having read that article, I can understand if you choose not to.
It is a tricky one. I've not had any problems without strong naming (that I know of) and so I'm leaning towards leaving things as is for now. I wonder whether you also might find life easier without signing too! I'm not sure it's gaining you anything (although the targets for your assemblies may be different from mine). If it would really help you to stick with signing and have various xyncro libraries also signed, I'd be open to setting up an alternative signing build and publishing those to a different feed - MyGet or similar perhaps. Although it would definitely need to be useful enough to justify it 😄
Thanks for the comments. I may give it a try with some of my work in future without signing and see what happens. I'll close the ticket
👍
No worries 👍 If you find a reason to come back and open this, feel free, I'm definitely open to arguments for doing so if it'll really help people!