The assembly strong naming conundrum

Developer
Feb 28, 2011 at 5:52 AM

Deciding whether to strong name assemblies is a pretty difficult decision. For the most part, I tend to adhere to the school of thought that if nothing was strong named (outside of framework assemblies), we would be better off. As long as you don't attempt to use the GAC (which has many issues), then strong naming just doesn't seem to give much tangible benefit. And it certainly does cause pain, because you start needing to add binding redirects left and right when you update some components.

Now, someone just filed a bug against WebActivator suggesting that it should be strong named to allow strong named projects to use it. And indeed, that brings up the major drawback of not strong naming an assembly: it can't be used at all by assemblies that are strong named!

One answer to that is to just tell everyone not to strong name their projects, but that's sort of a naive/unrealistic thing to say. The fact is that many people will use strong naming (for whatever reason), and it's very unfortunate to say that any NuGet package that is not strong named is completely unusable to them.

So this is causing me to rethink my position on this, and I'm wondering what others think.

Note that NuGet has support for easily generating binding redirects using the add-bindingredirect command (see my post). Right now, it doesn't happen automatically, but in the future we will make it do that, which in theory should take away most of the pain associated with consuming strong named assemblies.

In the end, we should all agree on some strong naming 'guidance' for NuGet package authors, and that is what I'd like to discuss here.

Feb 28, 2011 at 6:58 AM

I faced with the lack of strongnaming with WebActivator also, and since my projects are strongly named then I had to get the source code, add an SNK compile it, and I lost the benefits of using nuget at that point.

In my opinion we've some options:

- Require all submitted packages to have strongly named assemblies (as David said above) maybe it's unrealistic.

- Have a descriptor within package metadata which shows if the contained assembly signed or not, and when looking up dependencies it should be taken into account. Of course package listing should have a filter for this also.

 

Feb 28, 2011 at 7:08 AM
Edited Feb 28, 2011 at 7:08 AM

Point of view from Sebastien Lambla (OpenWrap), if you interested

http://codebetter.com/sebastienlambla/2011/01/05/strong-naming-assemblies-and-openwrap/

Developer
Feb 28, 2011 at 7:17 AM

Thanks Attilah, this is good feedback. We really don't want NuGet users to go through the pain of rebuilding the assemblies with a key, as it indeeds kills the benefit of NuGet.

Could you briefly explain why you decided to strong name your projects? Not saying it's wrong, just trying to understand :)  Is it because it needs to go in the GAC, or more for security reasons? Note that if NuGet package assemblies were to be signed, it would not provide any security benefits, since they're (mostly) Open Source, and the 'private' key would be freely available.

Feb 28, 2011 at 7:26 AM

I've started to run into this myself. With an installed base as large as NuGet's will likely get, I'm sure some people will be in an environment that requires their packages be strong named and some people will be in an environment that requires they NOT be strong named, so no single answer can possibly work for everyone. It seems to me that NuGet packages should provide a means to easily select what's needed on a solution by solution basis.

So perhaps having an option when adding a package reference that allows you to select among several choices:

  1. Leave all added assemblies as the package owner created them (i.e. what we're doing now)
  2. Automatically add binding redirects to sort of magically fix stuff
  3. Strip strong names from all added assemblies
  4. Automatically sign any assemblies that don't have strong names (already-signed assemblies are left alone)
  5. Automatically strip strong names from all added assemblies and re-sign them

The default could either be 1 or 2 since neither of those modify the files in the packages. When signing assemblies, NuGet would either use an SNK file provided by the developer or use a generic NuGet key. One nice thing about fixing things as you add packages is it should give everyone a way to solve their problems but doesn't require any changes to existing packages.

It doesn't seem like implemention should be too bad since there are existing utilities for signing and unsigning assemblies. I also like the option of re-signing all assemblies with a custom SNK file to ensure that assemblies aren't tampered with after shipping.

 

Feb 28, 2011 at 7:37 AM

Strong naming is coming from my Microsoft FTE times :-) Where it was a requirement for our projects to have strong names.

I'm not putting anything into the GAC but using InternalsVisibleTo attributes to enforce visibility within the product we're developing. If you're building "just" websites maybe you don't need strong naming at all. See Orchard, there are no strong names and "it works" :-))

So the cause to strong name or not to strong name an assembly is really depends on the "target audience". If it's a shipping product I'm sure you want to strong name it, if it's an internal framework you want to strong name it....but maybe there are scenarios where you don't need strong name at all.

 

I've read the OpenWrap write up from Sebastian and He summerized it well. Maybe it should be a very good idea to make the two packaging system compatible with eachother in terms of feature. Their assembly resigning feature can be a good solution in some scenarios.

Developer
Feb 28, 2011 at 7:38 AM

@sbussinger: Are there really environments that requires they NOT be strong named? What would be the reasoning behind that?

Sebastien Lambla has raised the possibility of stripping strong names and resigning (in some future OpenWrap version). It's certainly something that could be done, but it also has some serious drawbacks to consider before going down that road. The problem is that it locks you into getting all your bits through the package manager. e.g. suppose you get NHibernate (or whatever) through NuGet and it un-signs it for you (the official NH is signed). And then you get some random Foo library from some other source, where Foo uses the official (strong named) NHibernate. You now have a problem, and can't use Foo at all unless you go and change it to go against the unsigned NHibernate. So in a sense, the package manager made life easier for itself, but created hell for things outside of it.

Developer
Feb 28, 2011 at 7:46 AM

@attilah: my question for you is now: if you're in a situation where you think you need to strong name your assembly because it's a "shipping product", are you comfortable taking dependencies on Open Source assemblies? It feels like two worlds are a bit clashing here, and doing the on-the-fly signing of the unsigned assembly sorts of negate the claim that your product as a whole is 'signed' (well, it's all 'signed', but not in a meaningful way).

As a side note, note that OpenWrap doesn't do this automatic unsigning/resigning. It is just something that Sebastien has been thinking about as a possible future feature.

Feb 28, 2011 at 7:56 AM

It depends on the quality and licensing restrictions of the given project, there are plenty of good ones out there just to name a few: Log4Net, NHibernate, AutoFac, AutoMapper, etc...

Yes I know that resigning is a "planned" feature, but maybe it can be an alternative solution.

Feb 28, 2011 at 8:09 AM

I added strong naming to FluentValidation due to user requests as they wanted to use it in a strong named project. However, at this point I wish I hadn't done it (and am considering removing the strong name for the next release) as it makes upgrading that much more painful. It forces a recompile even if the assembly is binary-compatible with the previous release (which should be the case for point releases) or you have to resort to binding redirects.It ends up negating a lot of the flexibility of a package manager. I believe the OpenWrap strips the strong name off its packages, and I'd be quite happy if NuGet did the same.

Jeremy

Developer
Feb 28, 2011 at 8:18 AM

@Jeremy: thanks for your feedback. My take is that a lot of the pain your users encountered was due to having to manually add binding redirects (painful indeed!). My take is that once NuGet does this fully automatically (and this is coming), things will just work and you won't even care that it happened. Generally, what users care about is that after installing various bits, things "just run", and the fact that a few lines get added to their config won't be a concern.

So I think we can get there without resorting to more questionable techniques to modify/strip the strong name (see my previous comment on the issue with that).

Feb 28, 2011 at 12:27 PM

I'll reiterate my position here for those that didn't follow the link.

If packages are unsigned by default, signing them whenever a package is pulled with your own assembly would be quite fine, but indeed requires hot patching any assembly referencing that assembly. Now at build time this is realistically never a problem, as you probably don't care very much *which* signature an assembly has. If you however do runtime deployment, hot patching becomes a nightmare. Note that the nightmare also exists if assemblies are signed to start with, as you can't regenerate assembly binding redirects without a restart and a lot of xml.

The only sane thing to do for runtime is to sign nothing. The only sane thing to do for lib developers is to provide both versions, signed and unsigned, and let consumers chose if they want to buy into the nightmares introduced by assembly strong naming.

Coordinator
Feb 28, 2011 at 3:33 PM

Wanted to point out to David that just because a project is OSS doesn't mean the private key is public. I don't know of any OSS project that also puts their public key out there. That'd be a pretty bad practice. Usually, signing an OSS assembly with the project key lets you know that that particular build of the dll was signed by the real project team.

Typically, (as with Log4Net IIRC), the source code is delay signed. And if you want to build the source yourself, you replace their key with your own.

This is something NuGet could do automatically in theory provided we can workaround the complications that Seb mentioned with assembly references. Suppose when we install NuGet we generate a sn key that we store (but allow users to configure with their own key). Then when we install a package, there's the option to sn the assemblies. Either via a flag -EnsureSignedAssemblies, or through a global setting. Or automatically if we had a way to determine that it needed it with 100% accuracy. For example, the project you're installing into is itself signed, then we would know.

Having package authors include both signed and unsigned still runs into the problem of packages that depend on that package .Now they all have to provide signed and unsigned versions.

Feb 28, 2011 at 3:37 PM

Agree that providing both flavours doesn’t solve the problem, it just pushes the decision to the end developer rather than the package manager.

I personally would prefer unsigned assemblies always in packages with an option to sign them when they’re pulled down, and is something we’re investigating having in 1.2. You chose per solution the signing behaviour (aka unsign, sign, resign and bindings), but it is more involved.

From: haacked [email removed]
Sent: 28 February 2011 16:33
To: Sebastien Lambla
Subject: Re: The assembly strong naming conundrum [nuget:247827]

From: haacked

Wanted to point out to David that just because a project is OSS doesn't mean the private key is public. I don't know of any OSS project that also puts their public key out there. That'd be a pretty bad practice. Usually, signing an OSS assembly with the project key lets you know that that particular build of the dll was signed by the real project team.

Typically, (as with Log4Net IIRC), the source code is delay signed. And if you want to build the source yourself, you replace their key with your own.

This is something NuGet could do automatically in theory provided we can workaround the complications that Seb mentioned with assembly references. Suppose when we install NuGet we generate a sn key that we store (but allow users to configure with their own key). Then when we install a package, there's the option to sn the assemblies. Either via a flag -EnsureSignedAssemblies, or through a global setting. Or automatically if we had a way to determine that it needed it with 100% accuracy. For example, the project you're installing into is itself signed, then we would know.

Having package authors include both signed and unsigned still runs into the problem of packages that depend on that package .Now they all have to provide signed and unsigned versions.

Feb 28, 2011 at 4:41 PM

I would like to point out that bindingRedirects have there issues as well.  For example, when doing things like MSBuild task development, they are not a very good option, as they would require you to alter the app.config of msbuild.  The same is true of most any other development involving plugins to apps you don't own.  You can usually work around those issues by subscribing to AssemblyResolve event on the AppDomain, but that is pretty ugly, and assumes assemblies aren't in the GAC (not always true, consider System.Web.Mvc on local machines).

I like many of serialseb's suggestions.  I think in a world of package managers, strong naming is obsolete, and in fact inhibits you.  Obviously, that sort of goes against previous MS advice on strong naming, so that seems to be what really complicates matters.  How much is MS willing to change course, given that they have many customers who have strong named their stuff on the advice of MS.  We have to figure out how to get to a place that rids us of strong naming though, as it is causing considerable pain to .NET developers everywhere (at least that is what I observe).

Coordinator
Feb 28, 2011 at 4:59 PM

That’s the tricky part. We could decide ourselves to recommend not strong name signing, but I doubt we’d have much influence with the broad MS guidance. And given that, people will continue to strong name despite our guidance.

What I wonder is if we can’t try to have it both ways. We can recommend that assemblies in NuGet should not be strong named signed for best results. But if they are, we’ll do our best effort to make them work. Basically, no matter what guidance we give, I want to hedge our bets so the other camp isn’t left out to dry.

Phil

Developer
Feb 28, 2011 at 5:41 PM
Haacked wrote:

What I wonder is if we can’t try to have it both ways. We can recommend that assemblies in NuGet should not be strong named signed for best results. But if they are, we’ll do our best effort to make them work. Basically, no matter what guidance we give, I want to hedge our bets so the other camp isn’t left out to dry.

But this misses the scenario that started this thread. If packages like WebActivator are not signed, they can't be used from signed projects. We definitely need some story for that to work.

Coordinator
Feb 28, 2011 at 5:43 PM

Well that’s what I meant by “But if they are, we’ll do our best effort to make them work.”

I think if it’s feasible, signing the assemblies when the project you’re targeting is signed would be a best effort.

Feb 28, 2011 at 5:51 PM
haacked wrote:

Wanted to point out to David that just because a project is OSS doesn't mean the private key is public. I don't know of any OSS project that also puts their public key out there. That'd be a pretty bad practice. Usually, signing an OSS assembly with the project key lets you know that that particular build of the dll was signed by the real project team.

Typically, (as with Log4Net IIRC), the source code is delay signed. And if you want to build the source yourself, you replace their key with your own.

Yes, I totally agree! If we look at Orchard, there are some project references used by the product, but multiple dependencies include different versions and builds of the SAME product. This can cause some kind of confusion or even build/execution errors.

But on the counterpart, Microsoft never released CAB (Composite UI Application Block) in signed form, just source code was released and the included instruction told that "you have to build yourself". But developers asked for a signed version since if that signed with MS key the customer or the consumer should know that it's an unmodified product signed by MS.

So the whole topic is really scenario related and such NuGet should have an ability to tell the following about a package: Is it signed or not OR is it contains only source code. (I know it's not about the original topic, but since it can involve the package metadata it's a connected topic) :-)

Developer
Feb 28, 2011 at 5:55 PM

I think the confusion here is between producer assemblies (i.e. packages) and consumer assemblies (i.e. client apps). You wrote "We can recommend that assemblies in NuGet should not be strong named signed for best results.", and this does not account for the initial scenario. What would account for that scenario is to recommend that consumers don't sign their assemblies, which is a very different message to a different audience. And as I wrote in my first post, I don't think we can really affect consumers in that sense (they're following company practice, ...).

So if we want that to work (not strong named NuGet packages, and strong named client apps), our only option is for NuGet to auto-sign the assemblies. Really ugly stuff with its own set of issues, but if it comes down to that it is an option that should be kept on the table.

Coordinator
Feb 28, 2011 at 5:58 PM

Yeah, I think it should be kept on the table.

Developer
Feb 28, 2011 at 6:01 PM
haacked wrote:

Wanted to point out to David that just because a project is OSS doesn't mean the private key is public. I don't know of any OSS project that also puts their public key out there. That'd be a pretty bad practice. Usually, signing an OSS assembly with the project key lets you know that that particular build of the dll was signed by the real project team.

So what happens if I find a small bug in an OSS project that's blocking me? If I'm not able to rebuild it with the same key, then I'm in major hell. If I rebuild with my own key, then I can no longer use FluentNhibernate unless I rebuilt that as well? It would seem to negate a lot of the OSS benefits.

Feb 28, 2011 at 6:07 PM

I'm glad that people are more comfortable talking about resigning, maybe we'll end up implementing the same thing for both package managers.

That said, I'm confused as to where the conversation is going. If I understand the situation, David, you want to provide guidance around signing, but you are uncomfortable providing a "no signing" guidance until such a time that feature is implemented in NuGet? That leaves either the option of guiding towards signing or not guiding at all. Am I missing something?

Developer
Feb 28, 2011 at 6:33 PM
serialseb wrote:

I'm glad that people are more comfortable talking about resigning, maybe we'll end up implementing the same thing for both package managers.

That said, I'm confused as to where the conversation is going. If I understand the situation, David, you want to provide guidance around signing, but you are uncomfortable providing a "no signing" guidance until such a time that feature is implemented in NuGet? That leaves either the option of guiding towards signing or not guiding at all. Am I missing something?

The point of this thread is not to give guidance (which will be done via a doc/wiki page), but to gather information from various folk that will lead to deciding what the guidance is. So please don't read any specific post here as "this is the guidance". :)

Feb 28, 2011 at 6:39 PM

You may want to alter slightly your introduction message then, as it states "we should all agree on some strong naming 'guidance' for NuGet package authors, and that is what I'd like to discuss here". I assumed guidance writing was what you were after, hence my request for clarification of where you personally stand, and where MS/DevDiv/asp.net/SomeOrg may stand.

Coordinator
Feb 28, 2011 at 7:57 PM
davidebbo wrote:
So what happens if I find a small bug in an OSS project that's blocking me? If I'm not able to rebuild it with the same key, then I'm in major hell. If I rebuild with my own key, then I can no longer use FluentNhibernate unless I rebuilt that as well? It would seem to negate a lot of the OSS benefits.

That's always a risk. Hopefully, the library is flexible enough to workaround the bug using existing extensibility mechanisms.

This actually happened to us With Subtext. We are running a custom patch of Log4Net. What we did was rebuild it ourselves. Fortunately, in this case, only our library was calling into that specific one so we didn't have to rebuild dependencies.

But your right, if we had a bunch of other libraries relying on it, it would've been a real pain.

Mar 1, 2011 at 4:09 PM

Wanted to point out to David that just because a project is OSS doesn't mean the private key is public. I don't know of any OSS project that also puts their public key out there. That'd be a pretty bad practice. Usually, signing an OSS assembly with the project key lets you know that that particular build of the dll was signed by the real project team.

Now you do: xUnit.net puts our signing key into our source code repository.

Code signing is not a security measure. It's not to support putting our assembly in the GAC (it actually doesn't work in the GAC). It's merely to satisfy those who have a requirement to sign their own code.

We've suffered zero reported problems from this strategy.
Mar 1, 2011 at 4:56 PM

For what it's worth, there are quite a few projects that include the SNK files in their repositories. Autofac, Magellan, and NLog all do as well. As Brad said, simple strong naming isn't really a security measure anyway so including the SNK file in a public repository doesn't seem to be a problem.

I've been strong naming my assemblies because Microsoft was recommending it. After these discussions, I'll probably remove it now. I will likely start start code signing the assemblies though. I guess I always assumed that was part of what strong naming did, but when I just looked at a strong named assembly it's not code signed.

Whatever the final decision is on strong naming, can I suggest that the NuGet.exe package put a bit of enforcement behind it? For example, if the decision is that assemblies in packages should not be strong named, then NuGet.exe should check all assemblies and put up a blocking error if it tries to add an assembly that is strongly named. There could be a command line option to override that, but it would require a conscious effort on the part of the package developer to circumvent the recommendation.

Developer
Mar 1, 2011 at 6:20 PM
sbussinger wrote:

Whatever the final decision is on strong naming, can I suggest that the NuGet.exe package put a bit of enforcement behind it? For example, if the decision is that assemblies in packages should not be strong named, then NuGet.exe should check all assemblies and put up a blocking error if it tries to add an assembly that is strongly named. There could be a command line option to override that, but it would require a conscious effort on the part of the package developer to circumvent the recommendation.

I don't think we can go that far. We will have guidance, but in the end there will always be a mix of strong named and not strong named assemblies out there, and nuget's job is to do the best that it can to work with it using a combination of techniques (binding redirect, on-the-fly signing, ...).

Mar 3, 2011 at 9:06 PM

I just ran across another NuGet author struggling with strong naming problems. Check out this post: http://blog.markrendle.net/2011/03/01/simple-data-0-5/ where he talks about it. He finally stripped out his dependencies on the Reactive Extensions because they are strong named by Microsoft.

Removing dependencies on great frameworks like the Reactive Extensions is just another signal that we really need to solve this problem. Reactive Extensions are exactly the sort of thing that NuGet should be used for.

Developer
Mar 3, 2011 at 9:13 PM

In that particular case, binding redirects should completely solve the issue. The only reason this is coming up is that we don't yet do it automatically, and the command is undiscoverable. Our next release will address this.

I'm not disagreeing that we'd be better off if Rx was not strong named, but I do think we can handle it being strong named without causing much user pain.

Jun 7, 2011 at 11:33 PM

There's a fundamental disconnect here. 

  • If a signed application / dll that depends on unsigned dlls in a NuGet package, it cannot build
  • If an unsigned application / dll that depends on signed dlls in a NuGet package, it can build

Therefore, if NuGet packages that are hosted on the NuGet gallery include unsigned dlls, then a subset of users will be unable to use the package. Additionally, if NuGet packages that are hosted on the NuGet gallery always include signed dlls, then all users will be able to use the package.

Adding a check to "nuget pack" that requires all assemblies included as a "lib" reference to be signed, it would harm no one, and simultaneously prevent the phenomenally frustrating reaction that ensues when you try to sign something with an unsigned package dependency.

Putting aside all the religious ware about signing / not signing - don't we owe it to consumers of NuGet packages to ensure they won't run into scenarios where things break in a bad way?

-Joe

Coordinator
Jun 7, 2011 at 11:46 PM

We can’t possibly ensure that customers won’t run into scenarios where things break in a bad way. We certainly want to reduce the number of those cases. But I’m not sure this is the way to do it.

Let’s do a thought experiment.

Let’s imagine a world in which we changed nuget to not allow packaging unsigned assemblies. Let’s pretend 50% of folks sign their apps and 50% don’t (though in reality, I think it’s more like 10% sign and 90% don’t. For example, if I’m building a web site I host internally, I’m not going to go through the trouble of signing my web app assemblies).

So now, unsigned assembly can’t be packaged up and is very likely not going to be added to the gallery. So how has that helped you? Here’s an assembly you couldn’t use before that you still cannot use. But in this case, you’ve also excluded that assembly from 50% of the audience who could have use it.

Now, I know that in some cases, folks will just go ahead and sign it and re-pack. But I guarantee you that a large percentage of the folks will call NuGet a big POS that it can’t package up their assembly and will give up.

In theory, we could have nuget pack provide a warning about unsigned assemblies. That would at least raise awareness. For example, it could remind folks that those building signed apps cannot use it.

Maybe we even have nuget.exe simply sign it as part of the packing process. But I imagine there could be a lot of consequences to doing that. For example, what key do we use? How do we ensure the same key is used for each new version of the assembly. Etc.

Jun 7, 2011 at 11:59 PM

This is how we, as a community, start a race 'to the bottom'. We, as nuget package authors have a duty to create packages that are able to be consumed by consumers. I'd argue (and understand some would argue against) that signing your assemblies is good package etiquette - mostly because not doing so has poor side effects, that are more severe than those associated with signing.

  • sn -k <MyApp's SNK>
  • Right click the projects in your solution -> Properties -> Signing -> Do It

Really? Think of all the hoops that people jump through to create a nuspec, to test it. If there were a helpful message on the command line during nuget pack that said "Hey - it's really nice if you sign this. Otherwise, people who use your package in a signed app will be S.O.L. <Instructions Here>", that would be fantastic. Even if initially, we just warned people in this way, it might decrease the incidence of pain.

Another thing you could do when ingesting packages to the gallery would be to inspect the assemblies in /lib and determine if any were unsigned, and flag it so users know that they're potentially getting themselves in trouble by taking a dependency on an unsigned package. Lastly, it'd give you real statistics on the incidence of signing, rather than guestimates.

Thoughts?

Developer
Jun 8, 2011 at 3:48 AM

Note that assembly signing is a controversial topic, and many people believe that the .NET world would be a better place if no one ever signed anything. Clearly, there are pros and cons, but the point is that we definitely don't want to have NuGet force the issue on people. NuGet is a delivery mechanism for .NET assemblies, and its goal is not to make assembly authors change the way they build them.

One thing that has come up before is the possibility of auto-signing or auto-unsigning assemblies in some scenarios. We'll probably implement that eventually if the request comes up enough (though so far I don't think it has).

Coordinator
Jun 8, 2011 at 4:08 AM

I think having a warning describing the implications of packaging unsigned assemblies might be reasonable. Auto signing assemblies is also an interesting feature request. We’d have to think about that one. Would people object to that?

I doubt we’d disallow them though.

Yet another feature request is for NuGet to be able to determine that the package one is about to reference won’t work because an unsigned assembly in the package is being assigned by a signed application.

If you feel strongly about these, file them as feature requests and let’s see if they garner votes.

Jun 8, 2011 at 5:52 AM

You could make it the default to autosign unsigned assemblies and provide a command line option to not do that. That way authors that sign their assemblies aren't affected, authors that don't have a clue end up with signed assemblies everyone can use, and those that have a clue and really don't want them signed for some reason can easily accomplish that. It should still display a warning telling the authors to sign their assemblies, but if they don't it still ends up OK.

Developer
Jun 8, 2011 at 6:21 AM

I don't see auto-signing as something that happens at the time you create the package, but instead something that would happen at the time someone wants to use it in a signed project that won't work without it. My view is that the package should always contain the exact assembly that the author has created, and we should not mess with it at that level. Otherwise, it may create incompatibilities with other (possibly non-NuGet) components that reference it.

Anyway, we can settle on a design when/if we start work on this. As Phil suggests, someone needs to open a bug / feature request so it can get voted and prioritized against other things.

Jun 9, 2011 at 2:08 PM

In my entire software development career I have never worked on a professional project that used strong named assemblies. So I think that should sum up my perspective.

Jun 9, 2011 at 2:20 PM
Haacked wrote:

That’s the tricky part. We could decide ourselves to recommend not strong name signing, but I doubt we’d have much influence with the broad MS guidance. And given that, people will continue to strong name despite our guidance.

 

What I wonder is if we can’t try to have it both ways. We can recommend that assemblies in NuGet should not be strong named signed for best results. But if they are, we’ll do our best effort to make them work. Basically, no matter what guidance we give, I want to hedge our bets so the other camp isn’t left out to dry.

 

Phil

Phil I think you guys are giving yourself FARRR too little credit. The people that are interested in Nuget and what it does will value your guidance. After reading more and more of this post I can see why I've never seen a strong named assembly in the work place being that I've solely developed enterprise line of business ASP.NET web applications, that it offers really no purpose to that other than to generate nightmares for this type of application.

I agree with the rational of wanting to support to try to support both sides as this is always optimal. Nevertheless, I think you hit the nail on the head that the Nuget recommendation is not to strong sign (make the Nuget gallery publisher warn about this) and then after that do your best with the strong named assemblies. At that point if you ever hit a wall you always have the justification of dropping the stake in the ground and saying "this is why we recommend not strong signing, this scenario(s) is just unsupported"

Aug 15, 2011 at 3:15 PM

This conversation seems to be centered around a web centered world where I would agree that strong-signing doesn't make a lot of sense.  I realize that I'm probably in the minority case, but thought I'd throw a different perspective out there.

I work on desktop applications that are heavily based on plugin architectures.  The interfaces to the plugins are very stable and haven't changed significantly, however, underneath the plugin interface layer the guts of the application is built up in a set of assemblies that provide the bulk of the base implementation of our plugins.  It is critical that we allow multiple versions of these assemblies to be loaded by different active plugins.  Since the plugins never directly talk to each other, they each live in their own happy space and don't interfere with each other.

We also have started using NuGet for adding in the common packages and are waiting for the 1.5 release so that we can set up our own internal dependencies onto a local authenticated nuget feed.

If the entire NuGet space were to go unsigned, we would have to abandon our support because it would cease to function at all in our scenario.

Aug 16, 2011 at 12:25 AM
Unification can be done with appdomain isolation, and if sxs is needed one can sign assemblies on the fly. Thats how we very successfully build plugin-based architectures here.

Sent from my iPhone

On 15 Aug 2011, at 22:10, "fa3den" <notifications@codeplex.com> wrote:

From: fa3den

This conversation seems to be centered around a web centered world where I would agree that strong-signing doesn't make a lot of sense. I realize that I'm probably in the minority case, but thought I'd throw a different perspective out there.

I work on desktop applications that are heavily based on plugin architectures. The interfaces to the plugins are very stable and haven't changed significantly, however, underneath the plugin interface layer the guts of the application is built up in a set of assemblies that provide the bulk of the base implementation of our plugins. It is critical that we allow multiple versions of these assemblies to be loaded by different active plugins. Since the plugins never directly talk to each other, they each live in their own happy space and don't interfere with each other.

We also have started using NuGet for adding in the common packages and are waiting for the 1.5 release so that we can set up our own internal dependencies onto a local authenticated nuget feed.

If the entire NuGet space were to go unsigned, we would have to abandon our support because it would cease to function at all in our scenario.

Sep 21, 2011 at 1:18 PM

Strong signing is often required as soon as COM interop is needed. It is highly recommended when running desktop .NET applications on Terminal Servers to reduce the memory print of each loaded application instance. Therefore, not providing strong signed libraries makes life for desktop web developers a lot more difficult. 

Dec 15, 2011 at 9:17 AM

David Ebbo pointed me to this page.  There's obviously a lot more to the signing thing than adding the SNK file and the APTCA attribute.

After reading through the discussion: I think there is no single answer to the question "should assemblies in nuget packages be signed or not?".  So how about providing infrastructure support to nuget that would

  1. If a signed package is submitted, automatically creates an unsigned version
  2. If an unsigned package is submitted, automatically creates a signed version with a "nuget key"
  3. Provide functionality to nuget consumers to choose between the two versions

I'm sure there are issues lurking in this solution as well, but this sounds at first glimpse like an easy solution to the conundrum.

 

Feb 4, 2012 at 8:59 PM
Edited Feb 4, 2012 at 9:19 PM

My package - Json.NET - is used by a number of other popular packages - RestSharp - and strong naming is causing lots of issues for those packages.

I know there are many people who need the files to be strongly named because their own assemblies are strongly named or they need to deploy to the GAC for some reason, but at the same time unsigned libraries like RestSharp have to deal with the headache of assembly binding redirects each time a new strongly named version comes out- https://github.com/restsharp/RestSharp/issues/187

Things are even worse for Silverlight/Windows Phone developers because there is no way to assembly bind redirect at all - http://wpdev.uservoice.com/forums/110705-app-platform/suggestions/2511980-assembly-binding-redirection-support

What about adding the ability to NuGet to include both strong named and non-strong named assembly versions inside a NuGet package? NuGet could detect whether your assembly is strongly named and use the correct assembly or there could be some UI to choose one version. The dependency XML element could also have an attribute on it, i.e. strongnamed="true" that chooses the strong named assembly version.

Packages having both assembly versions will allow unsigned libraries like RestSharp to use the unsigned version and then people who do need the dlls signed can used the signed.

What do you think?

Feb 4, 2012 at 9:26 PM

Like James mentions, there are two issues that I don't believe were considered in this original discussion:

  • Silverlight and WP7 don't have the ability to do binding redirects.
  • Popular dependencies require strong naming if their dependents are also common dependencies (as in the case of RestSharp).

The way NuGet works right now, every time James releases an update and people manually pudate, my library and those that depend on it break. Being that WP7 is approaching the most common use case for RestSharp, this causes a lot of problems and forces me to rev RestSharp just for the updated reference.

Feb 4, 2012 at 9:58 PM
There's an easy solution. Enforce unsigned binaries in packages and allow the package manager to sign those unsigned assemblies with a key if needed.


--
Sebastien Lambla


On 4 Feb 2012, at 22:27, "johnsheehan" <notifications@codeplex.com> wrote:

From: johnsheehan

Like James mentions, there are two issues that I don't believe were considered in this original discussion:

  • Silverlight and WP7 don't have the ability to do binding redirects.
  • Popular dependencies require strong naming if their dependents are also common dependencies (as in the case of RestSharp).

The way NuGet works right now, every time James releases an update and people manually pudate, my library and those that depend on it break. Being that WP7 is approaching the most common use case for RestSharp, this causes a lot of problems and forces me to rev RestSharp just for the updated reference.

Feb 5, 2012 at 6:06 PM

I asked Microsoft's Jeff Wilcox (Silverlight Toolkit, 4th & square) what he thought about the Silverlight libs having strong naming:

https://twitter.com/#!/pedrolamas/status/161905248523395073

You can see here his reply:

https://twitter.com/#!/jeffwilcox/status/161905995646373889

So, I guess the real question is actually "whats the point in strong name signing a Silverlight library?"...

But I do like the thought of having a NuGet package for a SN signed version and an unsigned one! :)

Feb 5, 2012 at 6:21 PM

I agree with James' suggestions. Having a facility to provide both unsigned and signed versions of assemblies seems to be the optimal solution. 

Serialseb suggests: "Enforce unsigned binaries in packages and allow the package manager to sign those unsigned assemblies with a key if needed", but I think that's the wrong approach. If an assembly is signed, then it should be signed with a certificate that is created - and secured - by the application author. Signing is (in part) a security feature. Signing unsigned assemblies with an arbitrary certificate, or bundling private keys with a NuGet package are both suboptimal.

My preferred approach would be:

  • Allow package authors to include unsigned and signed versions of their assembly
  • Warn package authors that they should provide both if they only provide signed or unsigned versions of their assemblies, but not both
  • Allow package authors to specify a public key in the NuGet gallery, and validate new (signed) versions of assemblies against that public key to ensure authenticity
  • Ensure that when NuGet installs a package with signed assemblies that it validates the signed assemblies against the public key in the NuGet gallery
  • If a package author does not provide signed versions of an assembly, allow NuGet end-users to request anonymous signing of the assemblies when adding them to a project that generates signed assemblies
  • Provide the end user with a preference option and a command-line option to prefer signed or unsigned assemblies, and choose a default

In this way, users who do not wish to use signed assemblies can opt not to, and users who do wish to use signed assemblies can, while also validating that the assemblies are valid. When stuck up the river with no paddle, users who require signed assemblies (because they themselves are signing) can still get by, via anonymous signing.

If one thing is guaranteed on this topic - not everyone will agree... so if not in whole, is there a subset of this that people can get behind?

-Joe

Feb 5, 2012 at 8:18 PM
Unsurprisingly, I heartfully disagree with every single point made here.

If you use a package as a packaging unit, you don't give a flying monkey about the assemblies, you care about the package. Now I do realize it comes from the stance of the nuget team designing the package manager as an add-reference dialog on steroids (or as I believe it was stated many times "only automating what you already do manually"), but in my neck of the wood I deal with packages as the logical unit and thats it.

if you want to provide signing, it should be done at the package level.

Giving an assembly a strong name (which is what the problem is here with regards to versioning) does not ensure any kind of useful "security" as it is not a security feature at all, it's silly to even consider this.

If you want to provide strong proof of authorship of a package (and again, why would you accept signed assemblies and unsigned configs / ps scripts etc, it's completely ridiculous), then get package managers to implement signing of *packages* where the signature belongs.

If all packages contained unsigned assemblies and strong-naming was done only for those customers that have an end solution that require signing, then the problem would be easy to solve. You verify the *package*, you strong-name the assembly when required for those that require it.

As no one took a stand on the nuget side and completely ignored the problem by refusing to provide that guidance early on, we now have a combination of signed and unsigned, which is making things terribly complicated. You can argue that it was in the interest of market adoption to not take a stance, I'll argue it was in the interest of the community to decide on *something* way back when, before nuget was designed, when the rest of us were already building package managers.

As for validating signed assemblies with the server, this is also a terribly bad idea. You now impose a network roundtrip to verify part of your package content some of the time. What happens if i work disconnected? What happens for openwrap when we have an offline mode for installing packages?

I'll add once more to that equation that versioning assemblies independently of versioning packages is [insert colourful expletives here]. Why do you want two versioning mechanisms, that's why we created package managers to start with, because .net assembly versioning was designed to solve a problem and created much more friction and problems than they solved. That and mostly because the design on policy being per root config is completly idiotic and very painful.

I understand why the nuget crowd still overly focuses on assemblies and as such think it would be a good idea to provide both signed and unsigned assemblies as the default path. But for me it smells completely of misrepresentation of the problem, half-baked poorly designed solution.

I've been building and deploying openwrap in a very wide ranging set of projects with many different requirements over the years. People need assembly references that must be signed if their solution has projects that are signed. How we provide those signed assemblies can and should be up to the package manager.

The only debate that should be occuring should be compat with authenticode, as assembly rewriting will break any verification on that. It may be a problem for those customers that do have authenticode, or those that already strong-name their assemblies and need to support the existing deployments and migrate people over to package management.

For *those* scenarios you could think about providing a way to escape from a default that would serve everyone much better. You provide the happy path with the right architecture, you go after your 0.1% of customers with the complicated option.

Anyway, you guys can build the functionality of your package manager whatever way you want, but I would highly appreciate if any suggestion around the packages themselves (such as those proposals that would tightly couple packages to nuget even more, or the ones we should really be having around signing packages) was discussed with all the people that have code that have to interoperate with the technical choices that have so far been made in isolation, and in this I know I speak both for openwrap and for the likes of jetbrains. Try to think about the ecosystem that you have fostered and are dominating and try not to screw us up in the process, that'd be nice. package manager != package format != package servers, please put your architect hats on and try to design those independently, that'll make our life easier.


Seb
--






From: joefitzgerald [notifications@codeplex.com]
Sent: 05 February 2012 19:21
To: Sebastien Lambla
Subject: Re: The assembly strong naming conundrum [nuget:247827]

From: joefitzgerald

I agree with James' suggestions. Having a facility to provide both unsigned and signed versions of assemblies seems to be the optimal solution.

Serialseb suggests: "Enforce unsigned binaries in packages and allow the package manager to sign those unsigned assemblies with a key if needed", but I think that's the wrong approach. If an assembly is signed, then it should be signed with a certificate that is created - and secured - by the application author. Signing is (in part) a security feature. Signing unsigned assemblies with an arbitrary certificate, or bundling private keys with a NuGet package are both suboptimal.

My preferred approach would be:

  • Allow package authors to include unsigned and signed versions of their assembly
  • Warn package authors that they should provide both if they only provide signed or unsigned versions of their assemblies, but not both
  • Allow package authors to specify a public key in the NuGet gallery, and validate new (signed) versions of assemblies against that public key to ensure authenticity
  • Ensure that when NuGet installs a package with signed assemblies that it validates the signed assemblies against the public key in the NuGet gallery
  • If a package author does not provide signed versions of an assembly, allow NuGet end-users to request anonymous signing of the assemblies when adding them to a project that generates signed assemblies
  • Provide the end user with a preference option and a command-line option to prefer signed or unsigned assemblies, and choose a default

In this way, users who do not wish to use signed assemblies can opt not to, and users who do wish to use signed assemblies can, while also validating that the assemblies are valid. When stuck up the river with no paddle, users who require signed assemblies (because they themselves are signing) can still get by, via anonymous signing.

If one thing is guaranteed on this topic - not everyone will agree... so if not in whole, is there a subset of this that people can get behind?

-Joe

Feb 5, 2012 at 9:17 PM

Seb,

I think we agree on many points. 

  • There's a very valid use case for signing / validation at the package level to verify authenticity
  • You should cater to offline scenarios/ disconnected scenarios in any validation implementation
  • There should only be one versioning scheme - the package and the assembly versions should match

Signing an assembly and then distributing said signed assembly and a public key allows for use cases where you validate an assembly against the public key to determine if the assembly is valid. There are multiple reasons why you'd be interested in doing this, including file corruption related to network issues, or tampering, but other scenarios exist.

In any case - validation is a secondary or a tertiary concern. It should be done at the package level (which may choose to validate at the individual assembly level too) - but that's muddying the waters here. Put aside validation.

We need to simply solve end-user scenarios where:

  1. You sign your assemblies, and so require signed assemblies for all dependencies
  2. You cannot perform (or don't want to perform) binding redirects, and so prefer using unsigned assemblies

Further, package authors should be able to distribute one package that caters to 1) and 2).

So - an update to my previous list:

My preferred approach would be:

  • Allow package authors to include unsigned and signed versions of their assembly
  • Warn package authors that they should provide both if they only provide signed or unsigned versions of their assemblies, but not both
  • Allow package authors to specify a public key in the NuGet gallery, and validate new (signed) versions of assemblies against that public key to ensure authenticity
  • Ensure that when NuGet installs a package with signed assemblies that it validates the signed assemblies against the public key in the NuGet gallery
  • If a package author does not provide signed versions of an assembly, allow NuGet end-users to request anonymous signing of the assemblies when adding them to a project that generates signed assemblies
  • Provide the end user with a preference option and a command-line option to prefer signed or unsigned assemblies, and choose a default

From that list, the only impact to the package format (which i assume is of most concern to you) would be some convention to permit 1 or 2 assemblies for the same assembly name and framework version - indicating that the assembly is signed or unsigned.

If only one assembly is provided, you could infer whether or not the assembly is signed and use logic to determine the right course of action from there (i.e. anonymously sign unsigned assemblies if required / warn SL / WP7 users of the use of signed assemblies).

If two assemblies are provided (one signed, one unsigned), then you can provide enhanced functionality to the user.

I'm certainly not trying to "screw [the ecosystem] up" - and I'm only an infrequent contributor (and a heavy user) - so don't misinterpret my comments as being comments from the NuGet team as a whole.

-Joe

Feb 5, 2012 at 9:24 PM

If only one assembly is provided, you could infer whether or not the assembly is signed and use logic to determine the right course of action from there (i.e. anonymously sign unsigned assemblies if required / warn SL / WP7 users of the use of signed assemblies).

If two assemblies are provided (one signed, one unsigned), then you can provide enhanced functionality to the user.

This, I like! :)

Specially the part where we can add a signed and an unsigned version to the package (although this means the package size would increase!)

Feb 5, 2012 at 10:54 PM
Joe,

first, don't misunderstand me. I have a loud voice and a big mouth. Anyone that knows me (and sadly most americans don't, but most europeans do) knows that while I have opinions larger than life I'm also really never ever meaning anything more than just communicating passion about the opinions I formed.

<rant>When I talk about the nuget community (or sometimes referred to in the openwrap world as "the guys doing that other package manager with the less beautiful logo"), it's because I consider anyone involved in the project to be involved in the same way, as it's an OSS project. Reality is not what i'm going after here, just what it *should be* if microsoft was actually doing OSS projects the way they should be ran. In reality, we all know that the "community" would not be able to side on any architectural decision that would go againt what microsoft is paying for, which makes the project not open-source under my terms, until such a time as they adopt the approach Orchard did. </rant>

From your message, I heartfully agree that any validation is beyond the point of this conversation, and while it's a very interesting discussion (I've tried to get into that conversation with Phil Haack earlier, I think we're just going to implement package signing in OpenWrap and see if for once MS allows the ecosystem to adopt external impelmentations or if again the MS developers in their arrogance ignore us, implement something incompatible and win by sheer force or marketing dollars rather than technical qualities.

Let's follow the best approach, the one you introduced here, and analyse the scenarios. The way I see it we have the following scenarios all package managers have to deal with
  1. Solution has projects that are strong-named, they need signed references
  2. Solution doens't care about strong-naming as no project is signed
  3. Vendors want to strong-name assemblies with their own keys
  4. Vendors want to authenicode sign their assemblies with their own certificates

Now both 1 and 2 have two potential outcomes: a "concrete" build and a "package" build. The distinction is important because MS is completely over-reliant on the "concrete" build for historical perspective.

For the sake of clarity: a concrete build is a set of files that together form a traditional, by the book .net. I the web world thats what i call the godaddy test. If you have to deploy it to godaddy in a format, that format is a concrete build.

package builds are obvious, that's what a published package looks like when published as a package.

Let's review the solutions the way I see them (<arrogance mode=on>the right way</>)*:
1.a) if it's a concrete build, the user has no interest whatsoever in what happens behind the scene. Build->Publish should just work. The user should not give a flying monkey how the assembly gets added, gets signed, which signature it has or anything else. They added a package, they want a build and they want to deploy, end of. You can resign unsigned assemblies and you're ok. Auto-signing assemblies just works. Because it's a concrete build, you know everything about your solution binary outputs, so you can strongname all assemblies and updates all assembly references quickly and efficiently.
1.b) You're in a package build. If you followed 1.a the only way to get the right support is to not sign your assembly. Then things just work for concrete builds and it doesn't matter for package builds because the end result will always be a concrete build anyway, the right location to deal with assembly strong-naming.
2) Same as before. of course, the user doesn't give a rat's bottom about strong-naming in that case, even less than before. They're already using a package manager to manage their dependencies. they may have bothered to make sure their code only binds to the correct version range for a package. Expecting them to be burdened with the silliness of a secondary versioning scheme of strong-named assemblies in a package is just being delusional. Unsigning strong-named assemblies there works just fine for concrete builds. now for package builds, if you've reintroduced assembly identity through strong-naming, you're screwed. if you didn't it works.
3 and 4). Now I know for a fact that this is a minority of scenarios that just happen to have such an incenstual relationship with Microsoft that the marketing money the guys in redmond get is blinding them to how little a scenario it s. That said, they are paying customers (and more importantly, their customers are too) and it would be foolish not to support those minority scenarios, you'd lose customers for architectural reasons, a sure way to get fired (how I wish that applied to all product groups in MS).

So how do you solve 3) and 4)? Ill argue that 3 really is irrelevant whatsoever if you understand 1 and 2. If u don't, then you open yourself not to few cases but many, and you make it complex for everyone rather than complex only for those that want the complexity.

Now 4 is a good example where a minority has requirements that are market-driven, and you want to support *those* scenarios, and I say that in those scenarios you should allow signed and unsigned packages. What I really have an issue with is giving as defaults for all your user base the architecture built for the guys publishing their stuff to the GAC, infragistics, office and a few others. In terms of volume it's a minority, and architecturally you make their scenarios the way to solve everything. That is just plain horrible in how much complexity you introduce in the system.

I'll personally stop trying to advocate that position, I've been doing it for 3 years now and the only arguments I get are either "you don't know any better" (thanks David, same back to you) or "we need to support every scenario" (which I hope you understand from that email I think can be solved in a tiered approach rathre than blanket compelxity everywhere).

Either way, from a package perspective,k let's discuss signing, now that's something I need to introduce in openwrap soon, and there has been little discussions about it on your side (beyond Phil Haack telling me how digsig of the open package format thing you're using may be what you use, something I am completely against for many resons we can share on another thread).

Seb


* I believe this was a propsoed XML syntax by MS before XML 1.0 got drafted. I did support it very much.
--


From: joefitzgerald [notifications@codeplex.com]
Sent: 05 February 2012 22:17
To: Sebastien Lambla
Subject: Re: The assembly strong naming conundrum [nuget:247827]

From: joefitzgerald

Seb,

I think we agree on many points.

  • There's a very valid use case for signing / validation at the package level to verify authenticity
  • You should cater to offline scenarios/ disconnected scenarios in any validation implementation
  • There should only be one versioning scheme - the package and the assembly versions should match

Signing an assembly and then distributing said signed assembly and a public key allows for use cases where you validate an assembly against the public key to determine if the assembly is valid. There are multiple reasons why you'd be interested in doing this, including file corruption related to network issues, or tampering, but other scenarios exist.

In any case - validation is a secondary or a tertiary concern. It should be done at the package level (which may choose to validate at the individual assembly level too) - but that's muddying the waters here. Put aside validation.

We need to simply solve end-user scenarios where:

  1. You sign your assemblies, and so require signed assemblies for all dependencies
  2. You cannot perform (or don't want to perform) binding redirects, and so prefer using unsigned assemblies

Further, package authors should be able to distribute one package that caters to 1) and 2).

So - an update to my previous list:

My preferred approach would be:

  • Allow package authors to include unsigned and signed versions of their assembly
  • Warn package authors that they should provide both if they only provide signed or unsigned versions of their assemblies, but not both
  • Allow package authors to specify a public key in the NuGet gallery, and validate new (signed) versions of assemblies against that public key to ensure authenticity
  • Ensure that when NuGet installs a package with signed assemblies that it validates the signed assemblies against the public key in the NuGet gallery
  • If a package author does not provide signed versions of an assembly, allow NuGet end-users to request anonymous signing of the assemblies when adding them to a project that generates signed assemblies
  • Provide the end user with a preference option and a command-line option to prefer signed or unsigned assemblies, and choose a default

From that list, the only impact to the package format (which i assume is of most concern to you) would be some convention to permit 1 or 2 assemblies for the same assembly name and framework version - indicating that the assembly is signed or unsigned.

If only one assembly is provided, you could infer whether or not the assembly is signed and use logic to determine the right course of action from there (i.e. anonymously sign unsigned assemblies if required / warn SL / WP7 users of the use of signed assemblies).

If two assemblies are provided (one signed, one unsigned), then you can provide enhanced functionality to the user.

I'm certainly not trying to "screw [the ecosystem] up" - and I'm only an infrequent contributor (and a heavy user) - so don't misinterpret my comments as being comments from the NuGet team as a whole.

-Joe

Feb 6, 2012 at 12:22 AM

At the moment the key I use to sign Json.NET is private; I'm the only one that has a copy of it. Correct me if I'm wrong here about signing (I've never looked into signing that closely) but I've always liked the idea that if someone has my signed Json.NET assembly then it could only have come from me.

If NuGet did automatically sign assemblies would I have to include my private key in the package?

Feb 6, 2012 at 12:37 AM

@James

 

do you mean "strong naming" or "signing"?

Feb 6, 2012 at 12:49 AM
Nothing prevents me from providing a proxy server that removes your key and puts mine in place. Strong-naming is used to provide a unique identity for the version you have signed, at the same time preventing anyone from being able to rely on any other way to version exactly which version of json.net they want outside of what you baked in your assembly.

So i still think what you like in there, when looked at from the assembly-level perspective in a package-managed world, is useless, as you now provide a package with no identity, files that no one has any idea about (including executable powershell scripts), and some assemblies you are confident were signed by you. at that stage, you have achieved absolutely nothing of importance whatsoever, as anything you thought you did achieve can be implictyly counter-acted by the lack of package signing.

Just to make sure we're all on the same page. You "like" the idea of having your nice fancy signature in your package. People even suggested (wrongly) that this would provide for a security boundary as somehow someone could use a non-seucirty feature like strong-naming to sign things.

Let me create a nice package, with your lovely self-signed assemblies, add ilmerge to the package, write a powershell script that will then rewrite those assemblies by stripping that self-signed assemblies. I can do that now, any verification will be void (because the verification would still agree with your self-signed assemblies, yipee for strong naming), and you've closed absolutely no vector attack. None. Zip. Nada.

<rant> thats what you get for having a package format thats mostly imperative with loads of code as opposed to make them declarative so they can be useful to everyone. The powershell scripts are making this a nightmare, were a stupid absurd technical design decision for anything but downgrade/upgrade and make analyzing packages completley, utterly useless. Anything that uses webinvocator or chocolatey is completely, fundamentally useless unless you use the MS tools, packages are not self-descriptive, can't do anything with them. No one cares which is an even more worrying trend when it comes to MS-fed OSS </rant>

On a more constructive note, wouldn't the same be achieved by ensuring that a package that comes from you (with all that it contains) has been signed by you? I'm pretty sure we would get the trust (something I do believe in, at the package level, not at the assembly one) and at the same time it would actually be useful for the whole content of the package. *that* I agree with.

Whichever threat model you look at on those issues, there is *nothing* in there that serves the purpose you believe your strong-naming achieves. The lack of guidance on that issue (in a package managed world), the lack of best practices and years upon years of conflicting Microsoft documentation are getting us top the point where we are now: you feel cosy feely about strong-naming, but it serves none of the things that you would think it does becuase strong-naming was only designed to provide unique identificaiton of a specific version of an assembly, what you could call post-ctlctrl32 syndrom I suppose.

My argument is not to prevent an opt-out or argue for how nuget should build their package managers (if they gave a crap about that there probably wouldn't have been openwrap and nuget, we woiuld've built it together), but to make sure that packages don't standardize on practices that are only relevant to the customers of the VS/core/nuget-as-a-piece-of-installed-software.

I do have a feeling that asking MS-the-nuget-sponsor to provide giudance that goes against MS-the-10-years-content-about-strong-naming is a lost battle already, but what do you know. When theres lost battles like that i tend to stick around and continue anyway, so I should do that now.

Don't let the strong-naming malarchy be the default, for it is not what the default should be. Don't let your cosy feelings towards cargo cults lead the design work on what is new technology. And please don't ruin the package format, it's already in syuch a sad state on the nuget side I really wouldn't enjoy seeing more stupid things added to them.


From: JamesNK [notifications@codeplex.com]
Sent: 06 February 2012 01:23
To: Sebastien Lambla
Subject: Re: The assembly strong naming conundrum [nuget:247827]

From: JamesNK

At the moment the key I use to sign Json.NET is private; I'm the only one that has a copy of it. Correct me if I'm wrong here about signing (I've never looked into signing that closely) but I've always liked the idea that if someone has my signed Json.NET assembly then it could only have come from me.

If NuGet did automatically sign assemblies would I have to include my private key in the package?

Feb 6, 2012 at 2:37 AM
That is what I would consider to be a logical course, default to unsigned in packages with resigning, encourage people not to sign their assemblies if thy can avoid it, provide an opt out for those that want to deviate from the happy path.

It's also exactly the result of the discussion that was had in April or may 2011 (check the discussion board).

--
Sebastien Lambla


On 5 Feb 2012, at 22:24, "PedroLamas" <notifications@codeplex.com> wrote:

From: PedroLamas

If only one assembly is provided, you could infer whether or not the assembly is signed and use logic to determine the right course of action from there (i.e. anonymously sign unsigned assemblies if required / warn SL / WP7 users of the use of signed assemblies).

If two assemblies are provided (one signed, one unsigned), then you can provide enhanced functionality to the user.

This, I like! :)

Specially the part where we can add a signed and an unsigned version to the package (although this means the package size would increase!)

Feb 6, 2012 at 2:45 AM

James,

JamesNK wrote:

If NuGet did automatically sign assemblies would I have to include my private key in the package?

No. You should keep your private key private. There would only be one scenario where NuGet would automatically sign assemblies, and it would be done when installing or upgrading a package - not creating it:

  • The end-user is installing or upgrading a NuGet package in a project that will be signed
  • The package author included unsigned assemblies

This signing would be done by NuGet because if NuGet does not sign assemblies in this scenario, the end-user is left with one of two options (both of which are not good outcomes for the end-user):

  1. Stop signing their own assembly
  2. Stop using the package (otherwise, their build will fail)

- Joe

Developer
Feb 6, 2012 at 3:34 AM

Wow, looks like this thread came back to life in a big way! :)

It seems that for the most part, we've reached the same conclusion as earlier in the thread. My brief summary of it is:

  1. In NuGet packages, signing is discouraged, but not disallowed
  2. When consuming unsigned assemblies from signed projects, it would be nice if NuGet auto-signed assemblies with some NuGet key

So why hasn't #2 happened since this thread started? I'd say it's simply a matter of resources and prioritization. NuGet is a very small team with limited resources, so the core developers can only do so much. The good news is that NuGet is a fully Open Source project which welcomes contributions (and receives many), so I could totally see the bulk of this unsigning feature coming from external contributors.

As an aside, @serialseb, don't take this the wrong way, but I find your posts hard to read, because your concrete points (some of which I agree with) are interlaced with so much repetitive rant against Microsoft/NuGet/Xyz. This is not the most productive way to contribute to the conversation. Take this as my own rant :)

Feb 6, 2012 at 9:29 AM
David,

Is the advise on strong-naming in MS literature or the nuget one? Link would be handy.

As for the rants, hence the <rant> tag, I my offer a script for outlook that hides them.

At some point in the future I can see a world where I don't have to rant at all because people outreach and work together an are not being douches in other channels. Am pretty sure with a bit of effort on the nuget team part that could easily happen, we have after all done half that work with Haack.

--
Sebastien Lambla


On 6 Feb 2012, at 04:34, "davidebbo" <notifications@codeplex.com> wrote:

From: davidebbo

Wow, looks like this thread came back to life in a big way! :)

It seems that for the most part, we've reached the same conclusion as earlier in the thread. My brief summary of it is:

  1. In NuGet packages, signing is discouraged, but not disallowed
  2. When consuming unsigned assemblies from signed projects, it would be nice if NuGet auto-signed assemblies with some NuGet key

So why hasn't #2 happened since this thread started? I'd say it's simply a matter of resources and prioritization. NuGet is a very small team with limited resources, so the core developers can only do so much. The good news is that NuGet is a fully Open Source project which welcomes contributions (and receives many), so I could totally see the bulk of this unsigning feature coming from external contributors.

As an aside, @serialseb, don't take this the wrong way, but I find your posts hard to read, because your concrete points (some of which I agree with) are interlaced with so much repetitive rant against Microsoft/NuGet/Xyz. This is not the most productive way to contribute to the conversation. Take this as my own rant :)

Developer
Feb 6, 2012 at 4:42 PM
serialseb wrote:
Is the advise on strong-naming in MS literature or the nuget one? Link would be handy.

This is my view about it, which I think is shared by most NuGet core project contributors (and if it's not, they can speak up!). I don't know whether there is an official Microsoft position about this, but frankly I'm not sure how relevant that would be when it comes to NuGet.

Remember that NuGet is not a Microsoft project, but an OSS project under the Outcurve Foundation. Some of the core contributors are Microsoft employees, though the Project Lead (Phil) works at GitHub. Microsoft does integrate NuGet with Visual Studio, but the NuGet team chooses the direction of the project.

Your opinion about NuGet is welcome, but I do think it would be more impactful if it didn't involve calling everyone stupid and/or evil. :)

Feb 6, 2012 at 5:16 PM
We can have a discussion on the origin and relevance of my stance about the evilness of the nuget team by private emails it's not useful here. I won't start the discussion on project governance here either.

I don't call people stupid, ideas sometimes I do, when they are stupid ideas.

Now to the relevant bits: If nuget core contribs recommend not to strong name, an it's not in the doco, it'd be easier to approach the issue if your documentation reflected it.

--
Sebastien Lambla


On 6 Feb 2012, at 17:42, "davidebbo" <notifications@codeplex.com> wrote:

From: davidebbo

serialseb wrote:
Is the advise on strong-naming in MS literature or the nuget one? Link would be handy.

This is my view about it, which I think is shared by most NuGet core project contributors (and if it's not, they can speak up!). I don't know whether there is an official Microsoft position about this, but frankly I'm not sure how relevant that would be when it comes to NuGet.

Remember that NuGet is not a Microsoft project, but an OSS project under the Outcurve Foundation. Some of the core contributors are Microsoft employees, though the Project Lead (Phil) works at GitHub. Microsoft does integrate NuGet with Visual Studio, but the NuGet team chooses the direction of the project.

Your opinion about NuGet is welcome, but I do think it would be more impactful if it didn't involve calling everyone stupid and/or evil. :)

Feb 6, 2012 at 5:35 PM
Funnily enough, as i was researching the documentation for the guidance discussed here, I fell upon that entry from you:


Shows two things of importance, the relevant one being that at the time, when this issue was discussed, you seemed to be opposed to the idea of messing with binaries at all as it would be magical. Am I correct to understand that the core developers have now changed their minds and that I was simply not aware of that fact?

As for OuterCurve and Phil having stayed as project lead post MS departure, I don't think the picture is as simple as you paint it, but that's not my call to make or discuss, I'm not part of your project.

Seb

--


From: davidebbo [notifications@codeplex.com]
Sent: 06 February 2012 17:42
To: Sebastien Lambla
Subject: Re: The assembly strong naming conundrum [nuget:247827]

From: davidebbo

serialseb wrote:
Is the advise on strong-naming in MS literature or the nuget one? Link would be handy.

This is my view about it, which I think is shared by most NuGet core project contributors (and if it's not, they can speak up!). I don't know whether there is an official Microsoft position about this, but frankly I'm not sure how relevant that would be when it comes to NuGet.

Remember that NuGet is not a Microsoft project, but an OSS project under the Outcurve Foundation. Some of the core contributors are Microsoft employees, though the Project Lead (Phil) works at GitHub. Microsoft does integrate NuGet with Visual Studio, but the NuGet team chooses the direction of the project.

Your opinion about NuGet is welcome, but I do think it would be more impactful if it didn't involve calling everyone stupid and/or evil. :)

Feb 6, 2012 at 5:38 PM

The rhetoric and polemic aside, I like @serialseb's idea on how we could improve things. My thinking:

  • Don't just warn when people include a strong-named assembly in a package; make it *hard* to do so (require a flag to be set on the pack command or something similar, or maybe make them answer a prompt; even those seem too easy to me)
  • Change the PM to SN-sign assemblies *when needed* with a *NuGet owned-strong name*

I don't think supporting packages with both SN-signed and SN-unsigned assemblies makes sense; if you're willing to include an SN-unsigned assembly, you should be willing to let us SN-sign it as needed with a NuGet-owned key.

It's been a while since I've done anything with Authenticode signing, so I don't know what issues might be there. I haven't heard anyone complain about NuGet and Authenticode, so I'm not going speak to that.

I suspect that most, if not nearly all, packages with SN-signed assemblies on the NuGet feed today are doing it only to satisfy the assembly loading requirements of a consuming, SN-singed assembly. If there are packages that really do need a strong, unique identity for an assembly version, we give them a (painful) back door. (In some ways, I think this isn't really a valid scenario for using a package manager; you should allow the package manager to do the right thing in regard to dependency identity and the dependency graph.)

Developer
Feb 6, 2012 at 5:43 PM
serialseb wrote:
Now to the relevant bits: If nuget core contribs recommend not to strong name, an it's not in the doco, it'd be easier to approach the issue if your documentation reflected it.

That's a fair point, and we should indeed have such guidance somewhere in the docs. Though course it'd be an easier sell if we get an auto-signing feature in place.

As for my comment in the really early days of NuGet about not wanting to magically rewrite assembly, that's a natural gut reaction to something that is undeniably a hack. But I do now think that such hack is the lesser evil, and that an auto-signing feature would provide value.

As far as I can tell, no one here is in strong disagreement. As I said above, it mostly comes down to finding the resources to implement this in NuGet.

Coordinator
Feb 6, 2012 at 8:15 PM

Yeah. I was always against the idea of stripping the SN from a signed assembly. But I'm ok with the idea of us auto-signing an unsigned assembly to make it work.

I'm also ok with making it harder to put a signed assembly into NuGet, but I disagree with not allowing it altogether. There are always going to be some packages that are meant to be libraries which other libraries depend on. In those cases, it may make sense for the library to be signed.

Also, if we implement this, we have to consider the case where A -> B -> C and A -> D where A is unsigned. You try to install A into an app that is signed, now we have to auto-sign A. That also means we have to auto-sign B and C and make sure those references are correct. Also, suppose unsigned C is already installed. We have to upgrade it to our unsigned version.

I'm assuming we also need to update the assembly metadata's reference to the assemblies too, won't we? unsigned A's reference to unsigned B needs to be transformed to a reference to signed B?

Feb 6, 2012 at 9:28 PM

http://ryanfarley.com/blog/archive/2010/04/23/sign-a-.net-assembly-with-a-strong-name-without-recompiling.aspx

Signing doesn't look that hard, of course the devil is in the details (dependency chain, where to keep the new vs old assembly file, providing a UI to the use of what is going on, switching back and forth, detecting whether an assembly/project is signed, etc).

I'm happy to give me 2c on the feature but I don't have any time to pick up a new project and do work on it.

Feb 6, 2012 at 10:01 PM
From my tests, a module ref to a non-sn asm does resolve to an sn one quite happily, which is why our designed features were to include signing stripping.

Rewriting all module refs in IL is not that an issue because the end result of the build has a set of asms that's already pre-defined.

There are some other complexities that come from the workflows you may want to implement, it took me quite a while to cover all those, but then again our implementation covers more grounds than yours in that respect so we have more work to do.

That said, I see no reason why a consumer of an assembly shouldn't be allowed to chose what they want, including stripping of assembly references. The consumer is king and when there is a choice to make between doing what the user wants or what the library author wants, i'll always try to side with the user. Unless the user wants to do something stupid. :)

Seb

From: haacked [notifications@codeplex.com]
Sent: 06 February 2012 21:15
To: Sebastien Lambla
Subject: Re: The assembly strong naming conundrum [nuget:247827]

From: haacked

Yeah. I was always against the idea of stripping the SN from a signed assembly. But I'm ok with the idea of us auto-signing an unsigned assembly to make it work.

I'm also ok with making it harder to put a signed assembly into NuGet, but I disagree with not allowing it altogether. There are always going to be some packages that are meant to be libraries which other libraries depend on. In those cases, it may make sense for the library to be signed.

Also, if we implement this, we have to consider the case where A -> B -> C and A -> D where A is unsigned. You try to install A into an app that is signed, now we have to auto-sign A. That also means we have to auto-sign B and C and make sure those references are correct. Also, suppose unsigned C is already installed. We have to upgrade it to our unsigned version.

I'm assuming we also need to update the assembly metadata's reference to the assemblies too, won't we? unsigned A's reference to unsigned B needs to be transformed to a reference to signed B?

Feb 14, 2012 at 9:51 AM
Edited Feb 14, 2012 at 10:19 AM

Another approach to this problem would be better support for adding <bindingRedirects> for strong-named dlls.

I did a search and I came across a number of issues that touch on this - http://nuget.codeplex.com/workitem/1648 - http://nuget.codeplex.com/workitem/1541 - http://nuget.codeplex.com/workitem/232

I like the first one and the option that Haack raises of including metadata in the nuspec file to insert a redirect if required: <includeBindingRedirects>true</includeBindingRedirects>

This would make it easier for people to update strong-named packages (ASP.NET MVC, WebAPI, EntityFramework, Json.NET, etc) without their projects breaking underneath them.

Developer
Feb 14, 2012 at 5:26 PM

We do this already and it's automatic.

Feb 14, 2012 at 5:36 PM
I don't think this is a long-term solution though because it's not
obvious that it's happening. What we're seeing is that this gets added
in the local environment and if the dev doesn't notice (and they
almost always don't) and copy it to their production config the apps
break once deployed.

Automatically adding the assembly redirects has cut down the number of
issues, but we're still going to be facing problems related to strong
naming until we remove all strongly-named dependencies (which means as
much as I like Json.NET, it's on the way out for RestSharp because of
the strong naming).
Developer
Feb 14, 2012 at 7:08 PM

Indeed, we'd prefer to avoid the issue altogether by not having to deal with strong named assemblies. But for cases where there are such assemblies, the binding redirect logic we have today, while not perfect, does ease the pain in many scenarios.

Feb 14, 2012 at 9:17 PM
dfowler wrote:

We do this already and it's automatic.

There are posts up above about the add-bindingredirect command but they all say it isn't automatic yet. Is it now automatic? (I actually haven't used NuGet much myself)

If it is in now then that's great. Automatic binding redirects is a good step until NuGet supports automatic signing.

Developer
Feb 14, 2012 at 9:20 PM

It's automatic in some cases, but some of the bugs mentioned above do refer to scenario in which it does not currently happen automatically. e.g. http://nuget.codeplex.com/workitem/1648

Feb 14, 2012 at 9:30 PM

Ok. I've removed strong-naming from the Silverlight/Windows Phone assemblies in the Json.NET release I made a couple of days ago to fix that issue, and combined with automatic redirect binding for other platforms I'm pretty happy. I'll reevaluate what I do in the future when NuGet gets support for automatic signing.

Feb 29, 2012 at 6:31 PM

Just read (most) of this epic thread, and I assume no consensus has been reached on how NuGet should handle this? I've had plenty of people asking me to strong name NAudio (e.g. here, here, and here), but never did it because I always suspected that there might be some unwanted side-effects, and reading this thread still leaves me thinking that it might not be a good idea.

For my part, I like the suggestion of NuGet having an option to auto-sign an unsigned package whenever you add it to a strongly named project. This way, I can just tell people to install it with NuGet if they are referencing it from a strongly named project. I really don't care what key it is signed with - as seb points out, it doesn't really prove anything, although it might be best if there was a global NuGet key that was always used, so multiple signed versions of the same assembly were interchangable. Is there a FR we can vote on somewhere? I couldn't find one in the issue tracker.

 

 

Oct 30, 2012 at 4:11 PM
Edited Oct 30, 2012 at 4:12 PM

Any news/progress on this one?

Sorry, I didn't read the whole posts: tl;dr.

Oct 30, 2012 at 6:28 PM

I think most of the contributors on NuGet seem to be of agreement that we are not exactly certain what Microsoft's view is but in my opinion I don't think it really matters by the time it gets to us.  Since NuGet isn't a MS project but is what is considered an OSS project.

Although it seems that a lot of the main contributors are current or former MS employees and MS has integrated NuGet with Visual Studio.  Inferring that Microsoft is some kind of monster or boogie man seems unproductive at the very least.

_______________________________________

Meal Planning For Diabetics

Feb 4, 2013 at 11:56 AM
I need Ninject's OnRequestScope binding. So I install the Ninject.Web.Common package.

Problem - WebActivator is not strongly named.

I remove the reference to WebActivator (doable, apparently) but problem - referenced DLL is missing!

So I'm stuck, because WebActivator is not strongly named.

Why strongly name? Because Code Analysis / FxCop tells you to do so (you use CA, right?). Because otherwise strongly-named assemblies can't reference you. Because if you don't you can get (and I've seen this happen) random crashes due to corrupt DLL / EXE files. Because then the CLR's assembly loader will immediately warn you if there is a corruption.

Assemblies should always be strongly named. If other NuGet packages can do so, why not WebActivator?
Feb 4, 2013 at 1:04 PM
andrewwebb wrote:
Problem - WebActivator is not strongly named.

I remove the reference to WebActivator (doable, apparently) but problem - referenced DLL is missing!

So I'm stuck, because WebActivator is not strongly named.
Right on. And not only that, I FINALLY end up and come with decision of NOT using ANY (NuGet) libraries that has dependency to WebActivator.

Still, I'm not so sure of who will get the BENEFIT from this non-sense decision, if not actually being disadvantaged because of it.
Developer
Feb 4, 2013 at 4:23 PM
Edited Feb 4, 2013 at 4:26 PM
This thread discusses the issue. Summary is that while I'm ok with the idea of WebActivator being signed, transitioning without causing major pain is difficult as outlined in that thread. If someone comes up with a plan that doesn't cause more pain than gain, please follow up on that thread. But do read through it first or you might miss some subtleties. :)
Coordinator
Mar 4, 2013 at 4:34 PM
I have been wanting to try out Type Forwarding as a way to go from unsigned to signed. In theory, you should be able to add a new assembly into your package that is signed, modify the existing (unsigned) assembly to Type Forward all of the types to the new assembly, and be good. This would eliminate the need to create a new package and fork your dependent packages. It also prevents the need for a new namespace, which is great.

You could then, after a major version or two, delete the old (unsigned) assembly, and rename the signed assembly to the old assembly's name.

I haven't tried this out yet, but it seems like it should work and I think it would be a great approach if we could prove that it works.
Dec 2, 2013 at 3:30 AM
I ran into an issue recently when attempting to reference the NuGet package for Migrant from a project for a strongly named library. If I recall, our reason for strong naming was either to do with COM or ClickOnce or both but at this point I would have to dig through a lot of history be sure. For now I created an issue in the GitHub pages for the project as directed by the maintainers of Migrant but I'm unsure what advice to give at this point after reading the details here. Has a consensus been reached that clarifies what should be done for package consumers such as myself?
Jan 15 at 10:03 AM
I would strongly appreciate if all nuget packages were strong named.

The standard WiX Bootstrapper (WixStandardBootstrapperApplication.RtfLicense) needs the application it installs to be strong named. And in other projects we need the strong names for legal reasons so that we can proof that every assembly is the one that got the certification.

And Microsoft recommends that all assemblies have a strong name: http://msdn.microsoft.com/query/dev11.query?appId=Dev11IDEF1&l=EN-US&k=k%28CA2210%29;k%28TargetFrameworkMoniker-.NETFramework
Mar 11 at 3:04 PM
I should leave this here for anyone who stumbles across this thread:

https://www.nuget.org/packages/Nivot.StrongNaming/

This is targeted for signing the contents of NuGet packages that are using unsigned assemblies, in order to be able to link to these packages where the consuming project is strongly named. Access to the original source code is not required, and you may sign any assembly with your own strong naming key. You may also delay-sign if desired.

Details

All cmdlets accept pipeline input. The AssemblyFile parameter is aliased to PSPath, so it will
bind to piped files.
  • Test-StrongName [-AssemblyFile] <string[]> [<CommonParameters>]

    Returns true if an assembly has a strong name.
  • Import-StrongNameKeyPair [-KeyFile] <string> [<CommonParameters>]
  • Import-StrongNameKeyPair [-KeyFile] <string> -Password <securestring> [<CommonParameters>]

    Imports a simple unprotected SNK or a password-protected PFX, returning a StrongNameKeyPair
    instance for consumption by Set-StrongName. If your PFX file has a blank password, you must
    provide a SecureString of the empty string "". SecureString instances are returned from
    the Read-Host cmdlet with the -AsSecureString parameter.
  • Set-StrongName [-AssemblyFile] <string[]> -KeyPair <StrongNameKeyPair> [-NoBackup] [-Passthru]
    [-Force] [-DelaySign] [-WhatIf] [-Confirm] [<CommonParameters>]

    Assigns a strong name identity to an assembly.

    The -KeyPair parameter accepts a System.Reflection.StrongNameKeyPair output from the
    Import-StrongNameKeyPair cmdlet., which accepts either simple unprotected SNK files or
    password-protected PFX files.

    The -NoBackup switch directs the cmdlet to skip creating a .bak file alongside the newly
    signed assembly.

    The -Passthru switch will output a FileInfo representing the newly signed assembly to
    the pipeline.

    The -DelaySign switch will create a delay-signed assembly from a public key only SNK
    (it can also create one if the SNK contains both private and public keys.) This is useful
    if you can't get access to the full private key at your company. This will allow you to
    compile against previously unsigned nuget packages at least.

    The -Force switch will allow you to overwrite an existing strong name on an assembly.

    NOTE: You may supply -WhatIf to see what would be done, without actually doing it.
  • Get-AssemblyName [-AssemblyFile] <string[]> [<CommonParameters>]

    Returns a System.Reflection.AssemblyName instance from any assembly file.

FAQ: How Do I?

get the default package root folder

PM> $root = join-path (split-path $dte.solution.filename) packages

load an unprotected snk

PM> $key = Import-StrongNameKeyPair -KeyFile .\folder\key.snk
PM> dir *.dll | Set-StrongName -KeyPair $key -Verbose

load a password-protected PFX

PM> $key = Import-StrongNameKeyPair -KeyFile .\folder\key.pfx -Password (Read-Host -AsSecureString)

sign some unsigned assemblies

PM> cd (join-path $root unsignedPackage)
PM> dir -rec *.dll | set-strongname -keypair $key -verbose

(re)sign some assemblies forcefully

PM> dir -rec *.dll | set-strongname -keypair $key -force

sign only unsigned assemblies

PM> dir -rec *.dll | where { -not (test-strongname $_) } | set-strongname -keypair $key -verbose
Mar 14 at 6:32 PM
What would account for that scenario is to recommend that consumers don't sign their assemblies, which is a very different message to a different audience. And as I wrote in my first post, I don't think we can really affect consumers in that sense (they're following company practice, ...).

Let me try to describe the reasoning behind at least some of the practice of signing client apps. I hope to create a deeper understanding how strong naming is useful, and how nuget is currently not supporting it.

We use strong named assemblies to prove authenticity of the original code. We also use them to form a contract that the shipped code works with only the specific versions of the assemblies we tested and released. This is painful (e.g. binding policy), but the effects of non-publishers using client apps with untested versions of dlls is also painful. There are a few reasons why this happens: from overly pro-active IT to clients repackaging their software for internal deployment, to tampering. This is true even without involving the GAC, which we don't use. We get around some of the binding pain by using different versions for the strong name version (only major.minor) and the informational version (semver 2.0). This way, we can release patch versions without altering the strong name. Major and minor versions get a new strong name, but get replaced on disk, so get a new set of libraries, replacing the old. This way, we ensure that our client software is working with the versions we tested. It removes one whole category of uncertainty when it comes to troubleshooting in the field.

I look forward to having auto-signing working, which seems to be the best solution described.
Mar 24 at 8:41 PM
As a SharePoint developer (cough, grunt), would like everything to be signed. Can't use these libraries without manually building & signing on own. Defeats the purpose of nuget. I tend to think when philosophical ideologies get in the way of usefulness of a piece of code that it's time to conform. I look forward to getting strongly signed versions of these components.