Signing and/or Strongly Naming the Assembly

[TheHokieCoder]

Looking to get some feedback from the other developers and users of this package to see if we should start strongly naming the assembly. The StackOverflow answer linked below has some good points as to why it should be done. The main reason why I am for it is that a project that references the DotNetCasClient assembly cannot, itself, be strongly-named since the assembly is not strongly-named. In other words, all referenced assemblies of a strongly-named assembly must themselves also be strongly-named. Aside from that, perhaps the best benefit is one can be sure the assembly hasn't been modified outside of this project's official builds. And

There are some opinions out there that strong-naming is a waste of time or causes more headaches than it solves. So that's why I'm looking for opinions to make sure we make the best decision.

StackOverflow: Why use strong named assemblies?

[phantomtypist]

sigh

I guess somebody was eventually going to bring this up...

If this project was any more popular there'd be pitchforks and torches by now ;)

[phantomtypist]

Since all referenced assemblies of a strongly-named assembly must also be strongly-named, that leads to a problem with our NuGet "extension" packages discussed in #61 and #38.

We'd have to ensure the references inside those extensions (e.g. to Redis, Memcached, etc) also be strong named.

Here is a take on that: https://stackoverflow.com/questions/28584950/what-is-the-difference-between-stackexchange-redis-and-stackexchange-redis-stron?noredirect=1&lq=1

I've seen a lot of other projects, especially ones with NuGet packages, publish artifacts for both regular and strong named assemblies.

If you pick one, and only one, then the other side is impacted. It's not ideal, but it's the reality of the situation. I'd rather just "ride" the fence and publish both... my two cents.

[phantomtypist]

A good discussion I found a long time ago was the one with regards to Octokit.

Discussion: octokit/octokit.net#405

Outcome: https://github.com/octokit/octokit.net/blob/master/docs/strong-naming.md

[phantomtypist]

Personally speaking, I'm more on the side of "it's useless" if your the rationale for strong-naming is to prevent tampering/alteration... because of "security".

It's been a long time misconception. If you someone wants to truely prevent tampering of assemblies and impersonation you'd they'd go the route of Authenticode and Code Signing Certificates.

Strong-naming can easily be bypassed via Assembly Binding Redirects.

@pedrolamas put it so eloquently: https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/

[phantomtypist]

Here are some thoughts from the .NET core framework team: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md

They themselves even say that strong naming is a vestigial thing from a bygone era of .NET.... however there are some specific situations where they are required.

They do make it clear (in section 2) that strong-naming is NOT used for security, but instead identity. This is a huge misconception that everyone out there has thought for over a decade that somehow strong naming provided security. What they were confused with was "code signing" (along with Authenticode), which does provide security.

It should also be noted that they recommend open source projects check-in their SNK's (private keys) into the repo so that developers are still able to build their own versions. My good friends over at SSH.NET do exactly this.

I guess to end my long winded discussion, I'll make the proposal that:

1. We do strong name the assembly and also include the SNK in the repo.
2. Keep the NuGet package DotNetCasClient with non-strong named assemblies for backwards compatibility and
3. We publish a second "main" NuGet package that contains the strong named assemblies with a name such as DotNetCasClient.StrongName. This follows the convention Stack Exchange uses (https://www.nuget.org/packages/StackExchange.Redis.StrongName/)

[phantomtypist]

@scottt732 @mmoayyed @serac @TheHokieCoder

Your thoughts on the thread and more specifically my last comment with the proposal?

[TheHokieCoder]

@phantomtypist Thanks for all the links/references.

Personally speaking, I'm more on the side of "it's useless" if your rationale for strong-naming is to prevent tampering/alteration... because of "security".

No, my goal is not to prevent tampering, but merely to indicate it. In reality, providing little more usefulness over supplying hashes of the binary with the difference being that with signing the user doesn't have to perform the verification themselves. Right now, in isolation, there is no way to look at two v1.1.0 copies of the same DotNetCasClient DLL and be able to know which is the official build that came from this project.

That being said, I am totally fine if the juice isn't worth the squeeze. I didn't find any mention of assembly signing in any of the previous issues, so I thought I would bring it up. I definitely don't want to start a war on the issue!

[phantomtypist]

@TheHokieCoder it's not a lot of effort for me to implement and make the second package. I can see there being a benefit for people that need a strongly named package. I'm going to assume someone out there has probably already cloned this repo locally and strong named the assembly for their use internally because we haven't done so.

If it makes it easier for even that one person to get updates (instead of them pulling and rebuilding themselves internally at their org), I'm all for it.

[phantomtypist]

Differences between signing and strong naming: https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/

[phantomtypist]

I'd like to know if anybody that uses this project has a need for an actual signed (using Authenticode) assembly? (i.e. since because this project deals with authentication, it might be important for someone to verify the assembly being used isn't impersonated or tampered with.)

The thing most people (indirectly) ask for with regards to this topic (here and elsewhere) is strong naming, which only verifies a unique identity of an assembly.

[TheHokieCoder]

@phantomtypist Thanks for that article on Authenticode vs. strong naming. My naiveté with respect to the whole signing vs. strong naming concept lead me to believe that the two were one in the same, as far as .NET goes. Now that I understand things much better (kudos to all your helpful links) I am firmly of the stance that in my use cases I am only interested in signing my assemblies. But signing my assemblies do not require that the DotNetCasClient assembly be signed, so I no longer see this issue as a "must have".

I think it would be a benefit to all who use this package to have a signed assembly so that they can easily tell that the client was built using the open-source code in this project and not from someone else's (possibly) modified clone. Again, like you already mentioned, this client plays a middle-man role in client authentication, so verification of the assembly should be pretty important.

I don't know if Apereo can provide a code signing cert for this project to use, or if one would have to be purchased from a vendor, so that would be a hurdle to get over.

So my vote would be +1 for signing the assembly, if obtaining a certificate wouldn't be too much of a hassle/cost. As far as strong naming the assembly, I am neutral on the issue. If there are others who would find it useful, then I am OK with doing it. But if no one really cares, then we should leave it as is.

Should we rename this issue to something like "Signing or Strongly Naming Assembly" to better indicate the topic at hand?

[phantomtypist]

Strong Naming

I believe strong naming really shouldn't be an issue anymore because people making web applications should be deploying the dependencies/references inside the app's bin folder (except for core framework ones.)

The whole strong naming thing, for uniqueness, came from the darn GAC. I avoid putting stuff in there like the black plague. And if you want to deploy your stuff to Azure, AWS, etc that's just not gonna happen unless you pay a chunk load more money for a full VM.

While I have this thing against strong naming, I will however proceed to create a secondary artifact in the build process that gets strong named using an SNK to be included in the repo. That strong named version of this project/assembly will then be pushed as a second NuGet package named DotNetCasClient.StrongName. The development effort for this is minimal and I don't think it will affect technical debt in the project going forward. The strong named assembly will be there for whoever wants to use it and go through the nightmare that strong naming can some times lead too ;)

The existing assembly and associated NuGet package will remain not strong named for backwards compatibility purposes.

Signing

I too believe there is value in signing the assembly. I'll have to touch base with @mmoayyed to find out how Apereo handles code signing certificates with their other projects.

[TheHokieCoder]

@phantomtypist Did you get anywhere with Apereo with respect to code signing?

[phantomtypist]

No. Let me ping them again.

[TheHokieCoder]

Did you ever find out if the Apereo org has a way to get a code signing cert for this project? If so, I am curious where in the project ecosystem a cert could be stored that wouldn't be publicly available, but available to the build pipeline for signing official releases.

[phantomtypist]

Me and @mmoayyed settled on me getting my employer (university) to obtain one. We get them free from our InCommon CA. I received it back in December.... will probably have time in June to implement it in this project. I have to play around with how I'm going to architect this into the CI pipeline.

[phantomtypist]

@TheHokieCoder if you have any ideas for using the cert in the CI process, not publicly exposed, let me know here or on Gitter or email. Like I said I'm considering a few things. I've reached out to a few other people that already do this to get their perspectives... and it's all over the place :-/

[TheHokieCoder]

Great! That sounds good. We (mostly you) should have the client much more stable by then, so it'll be a good time to have the assemblies signed so consumers can verify they came from an official build of this project.