2

Closed

Strong name signing of assemblies

description

It is impossible to use the nuget-package directly inside other project that need to be strong name signed.

Is it any possibility to make a signing key for the YUI (and ECMAScript) library as well so the nuget-package is signed?

I can make my own build of YUI-packages (and ECMAScript) packages that are signed, the bad with that is I can't use third-party librarys that depend on the unsigned version of YUI-packages without recreating that packages also.

Adding strong name on the assemblies will break all previous assembly redirection so it is important to bump major version number to notify developers on the big breaking change.
Closed Mar 2 at 10:21 PM by purekrome

comments

freeranger wrote Sep 13, 2013 at 10:35 AM

Hi,

I am curious - what is your use case here that you need the package signed?
YUI is typically used in a pre/post build scenario, not directly referenced in another project, and certainly not in a scenario where it needs to be signed.

Also, you say: "I can make my own build of YUI-packages (and ECMAScript) packages that are signed, the bad with that is I can't use third-party librarys that depend on the unsigned version of YUI-packages without recreating that packages also."

You still wouldn't be able to use third party libraries that depend on the unsigned version whether we made a signed version available or not....

Tasteful wrote Sep 13, 2013 at 11:42 AM

Example YuiCompressorTransform is a bundle transformer that is included and executed at runtime and will not be executed in pre/post-build step. This transformer can then be used from administration view to change the CSS and automatic get it compressed out to the client.

In the application that we are building we have build something simular that works with .net 2 and our application need to be signed to meet the customer requirements for their environment.

We have 3 options today
  • Compile own signed version
  • Use the old YUI 1.7.1.0 that still is signed
  • Switch to other library
If all that need a signed version of the YUI will make own signing non of the signing keys will match, if the nuget-package is signed all will use either the unsigned version or the signing version with same signing key. This will not fix the issue to use other package that use the unsigned version if multiple versions exists.

freeranger wrote Sep 15, 2013 at 4:26 PM

Have to wait for PureKrome to take a look at this - nuget packages are his domain....as indeed is ECMAScript.

WAKE UP PK!

purekrome wrote Sep 16, 2013 at 12:51 AM

Hmm.. I've never actually signed a DLL so i'm not to sure of the implications. Do all the -depedencies- also have to be signed?

I know it's not hard to sign a dll -> just change the dll properties in Visual Studio, etc.

I'll talk to some of the guys in JabbR and see what they think. Watch this space.

BTW: I'm attending a conference today (i'm at it right now) so i'm out for a few days.

NaturalCause wrote Sep 30, 2013 at 10:30 AM

This should be closed as "Wont fix"

freeranger wrote Sep 30, 2013 at 10:52 AM

Why?

ThomasPP wrote Sep 30, 2013 at 12:59 PM

Our use case is simple:
  • We need to sign our DLL (to be able to use GAC), so all our dependencies needs to be signed.
  • Currently some of our dependencies are not signed so we have an extra step after installing/updating YUI Compressor to sign the DLL.
Maybe, it would be possible to have two NuGet Packages ? (one signed, one left unsigned)
Or two dll inside one package (not sure it's possible)

I'm not sure to understand why you would want to not sign YUI? (Except if you have unsigned dependencies)

Thank you

freeranger wrote Sep 30, 2013 at 1:52 PM

My question was to NaturalCause who said this issue should be closed - I understand why you want signed assemblies.

No decision has been made to sign or not sign so there is no reason to close the issue at this time

purekrome wrote Oct 7, 2013 at 12:04 AM

@ ThomasPP

Ok, so I asked about this on the net and on StackOverflow and .. well ... there's a MASSIVE number of people saying: NO. I also respect a number of those people on twitter (eg. Betts, Robbins, Dorrans, Sheehan, etc)

So .. i'm swayed to say NO also.

-BUT-

I understand your nasty position :( Using GAC (oh!! the SIGH!!!!! poor thing!!!) So i'll have a chat to some of these in person to see what options I have here.

purekrome wrote Mar 2 at 9:49 AM

Ok. Old thread I know.

I'm NOT going to provide a SN'd dll on Nuget.

But ..

I could probably provide the dll via zip ... if i can figure out how. This way, the option for a strong-name'd assembly does exist without anyone having to go through the motions of clone/compile ...

if that interests you, I could try and do that?

freeranger wrote Mar 2 at 11:09 AM

Otoh if there's not much demand for it, well the source code is there for anyone to download and nuget isn't the only way to manage a dependency...so perhaps those that need signed assemblies can build and sign themselves?

purekrome wrote Mar 2 at 11:32 AM

That's always been the case (thank you OSS :) ).

but the question was fair - instead of me doing that for each release, just make the nuget package SN. But because I'm deciding NOT to SN it .. there might be a slightly kinder way - offering a zip.

(personally, I can't be ass'd to do that, but I for the sake of making people happy.....)

Tasteful wrote Mar 2 at 12:15 PM

To provide a zip that is strongname signed will be the same job as creating a nuget package.

For me that is no longer needed, have clone the code myself and signed it with the key that was used in old releases.

The problem to build and make 2 packages directly is that the dependency of the ecmascript tha you have on github also need to be signed, so creating conditional builds is little more complicated.

I have a fork both on codeplex and github for both dll that are signed if anyone are intrested.

purekrome wrote Mar 2 at 10:10 PM

To provide a zip that is strongname signed will be the same job as creating a nuget package.
It's similar, but definately not the same .. especially with regards to 'finding' the package and consuming it. Basically, I don't want to confuse the end-user by offering two packages and they will go "huh? which one? what's SN? why do my feet always smell? ... "
For me that is no longer needed, have clone the code myself and signed it with the key that was used in old releases.
Great! I'll close the issue then. I think your actions have more or less confirmed my thoughts -> advanced users who need SN can just clone/compile and use those dll's. they can even throw em up on myget if they are really hardcore.

kewl!

closing this now :)