Signed Octokit Releases - Yea or Nay?

[shiftkey]

So #404 landed, and I wanted to have a proper discussion about whether we should do this in an official capacity for Octokit releases.

So let the fur fly (remember, bonus points for good reasoning and being gentlemanly) and I'll check back in a few days to see who is left standing...

[rprouse]

I submitted the pull request, so I will be the first to jump into the fray.

First, let's make sure it is clear what we are talking about. This issue is about Strong-Name Signing, not signing the code with an SSL certificate purchased from a signing authority.

Strong-Name signing just provides managed assemblies with a globally unique identity, whereas the second is used to verify the publisher of the application, in this case GitHub. The signing key for strong naming is just a key that a developer creates on the command line and checks into the repository. Ideally they would be secured, but that does not work for open source projects.

Public libraries should always be strong named otherwise they cannot be used by applications that are strong named or in Click-Once deployments. In my case, I am working on a Visual Studio extension which should be strong named. I can get around it, but that will limit what I can do in the extension.

Look around at most of the most popular non-Microsoft open source libraries, they are all signed and are not putting artificial limitations on their users. Here is a short list, Newtonsoft.Json, NUnit, NLog, Ninject, DotNetOpenAuth, log4net, AutoMapper, Castle (Windsor, MonoRail, etc). In all cases, their keys are in their repositories.

If you want to troll around your bin directory and see what is signed, sn -T Ninject.dll

So, to sum up, Strong-Name signing costs you nothing and allows your library to be used everywhere and play nice with others.

Okay, who's next? Gloves off, Internet fight time...

[phantomtypist]

LOL.

This is an issue on another public project I try to help with.

Let me throw this idea out there that I've been toying around with. (Disclaimer: I've seen the idea on a few projects so it's not an original idea.)

What if we were to set up the build server to generate two different sets of assemblies, one Strong-Name signed and one not signed? As a byproduct it would also generate two sets of NuGet packages. The unsigned NuGet package would continue to have the same name. The signed NuGet package would be named something along the lines of "Octokit-Signed".

The one downside to introducing signed assemblies, only, is that it could lead to assembly version redirect issues for end-users. log4net ran into this issue and got a little backlash from it.

I'd like to think it makes people on both sides of the fence happy. Thoughts?

[haacked]

Two sets of NuGet packages is very bad for libraries that other libraries depend on. What package should they reference? This might not be as big a deal for Octokit.net.

I believe that eventually, strong naming as we know it will be burnt down by the CLR team and replaced with something better.

Using Octokit in Visual Studio seems like a core scenario to me. I would be 👍 to taking the JSON.NET approach.

1. Strong name Octokit.net and Octokit.Reactive.
2. Freeze the assembly version at 1.0.0. The CLR assembly version of these DLLs would never change again.
3. Continue to increment the NuGet version.

In this plan, NuGet becomes the unit of deployment, not the assembly as has traditionally been the case with .NET.

By freezing the assembly version, we don't have to worry about binding redirect problems in the future. Octokit is pre-release right now so I don't care about introducing breaking changes like this at the moment.

[haacked]

Also, while you should never rely on strong name keys to verify an assembly, I do worry that people still do. So we should consider having a set of private keys in the project for builds and another set for the official releases that we keep private.

The alternative is just to have one set of SN keys and have them in the project and hope people by now understand SN verification is a bad idea.

[phantomtypist]

@haacked, I do agree that two NuGet packages are a bad idea. That's why the other project I'm involved in hasn't proceeded in any direction yet.

Freezing the assembly versions would work to resolve the binding redirect (I forgot the name for that) problems. I can't think of any downside to this off the top of my mind, but can you think of any?

[rprouse]

@haacked, I also agree that two sets of NuGet packages is a very bad idea, especially if you do freeze the assembly version number which takes away the only downside that I know of. We've been having the same discussions over on the NUnit team recently, but at least we have the advantage that unit tests are recompiled often.

As for keeping the key private, if you want to, you could have the build check for the existence of a key and generate one if it doesn't exist. Then you just need to drop the key in on the build server.

That said, from my experience, most open source projects just check it into the repository. I think the downsides of that are much lower than the consequence of ever losing the official key which would be a breaking change if you had to regenerate it. Plus there is just the headache of keeping track of the official key and making sure it is always used for the production builds.

[akoeplinger]

+1 on freezing the AssemblyVersion number. The AssemblyFileVersion can be used to store the real version number instead.

If I'm not mistaken, you could increment the assembly version on major releases (i.e. 1.0.0, 2.0.0, 3.0.0) as those would be breaking and require recompilation anyway when following SemVer?

[rprouse]

I was thinking more about freezing the assembly version number and wonder if it is necessary for this project. There are usually only problems for libraries that tend to get pulled in from other libraries. For example, when a project uses two NuGet packages that reference different versions of log4net.

I don't think that will be a problem for this project as it will probably be a top level package.

[rprouse]

If this ends up getting the thumbs up, I would be happy to take my original pull request and incorporate whatever is decided here. Just let me know.

[pkarlsson-codes]

If the version number was to be frozen. What would the benefit be to freeze it indefinitely as opposed to updating it for major releases (i.e. breaking changes)? Don't we want it to break at a predictable time if the assemblies are not actually compatible?

Also this 👍

I don't think that will be a problem for this project as it will probably be a top level package.

Was going to say that I would also rather see the key be public and checked into the repository. But considering the above statement, using a private key becomes much less of an issue and I really have no preference one way or another re: public vs. private 🔑

In summary I would say Sign it!
If we have to freeze the version number (not convinced that we do) at least update for major releases.
No preference on public/private key for official releases.

[shiftkey]

I hate it when @paulcbetts writes what I wanted to

reactiveui/ReactiveUI#43 (comment)

Every time a new contributor comes along, they now have to have an extremely demotivating fight with Visual Studio to get the project to build, or to replace the official binaries with ones they've built for testing.

Anyone have a sample/blog post around about doing this without touching the csproj files so we can avoid this pain?

But I'd lean towards Authenticode signing for this sort of thing, because It's The Real Deal.

[haacked]

@shiftkey what paul writes about is a non-issue if we just include the official snk in the solution. Problem solved.

Remember, we're not doing this for security reasons. We're doing it so people can use Octokit.net within a Visual Studio extension. I bet you can see the appeal of that to me. 😉

[anaisbetts]

@haacked I mean, I currently use ReactiveUI in a Visual Studio Extension, I don't know where this "You must SN every binary" is coming from

[haacked]

I mean, I currently use ReactiveUI in a Visual Studio Extension, I don't know where this "You must SN every binary" is coming from

People keep telling me this 💩. If we don't need to sign it, then let's not. What the hell? Can I get some good intel here? 😏