Nest.Signed and Nest.Connection.Thrift.Signed only delay-signed, needs to be full signed

[maximpashuk]

Version 0.11.7.0

Nest.Signed.dll and Nest.Connection.Thrift.Signed.dll are only delay-signed by a public key.

If test Nest.Signed on a clean machine, you will get an error "Strong name signature could not be verified"
Very similar to
http://aspnetwebstack.codeplex.com/discussions/444111

Delay-signing is not enough for production.
For now users must skip strong name verification on theirs machines to work with Nest.Signed.

Please re-sign Nest.Signed by a full key (public+private).
This will fix the problem.

Signing dll by a full key will not compromise this key.

[Mpdreamz]

Crap, I had problems getting ilmerge to create a valid dll unless i passed the /delaysign parameter (it would just hang).

I debated on checking in the secret key, I'm not against it the only reason not too i could think of is that in case nuget.org ever gets compromised.

Can you review how I'm signing the dlls here:

https://github.com/Mpdreamz/NEST/blob/master/build/NESTBuild.proj#L77

[maximpashuk]

From my point of view you should not check-in private key, keep it in gitignore.
But you should use private key then signing.
Using public key for signing will hang until you set delaysign, this is true.

Can you try to use private key then signing?

/keyfile:$(MSBuildProjectDirectory)\keys\private.snk

I have a success then I use my key. Also I use ilmerge from nuget package, probably this depend of your tool
https://www.nuget.org/packages/ilmerge

P.S. Actually private.snk is not a good name, good name is fullkey.snk, because crypto keys always stay together. Sometimes you can export public part to public.snk, but you never can export private-only part via sn.exe.

[Mpdreamz]

Cheers, yeah i was rereading

http://msdn.microsoft.com/en-us/library/6f05ezxy.aspx

and they also deliberately do not not call it private.snk either.

On Tue, Nov 5, 2013 at 12:29 PM, Maxim Pashuk notifications@github.comwrote:

From my point of view you should not check-in private key, keep it in
gitignore.
But you should use private key then signing.
Using public key for signing will hang until you set delaysign, this is
true.

Can you try to use private key then signing?

/keyfile:$(MSBuildProjectDirectory)\keys\private.snk

I have a success then I use my key. Also I use ilmerge from nuget package,
probably this depend of your tool
https://www.nuget.org/packages/ilmerge

P.S. Actually private.snk is not a good name, good name is fullkey.snk,
because crypto keys always stay together. Sometimes you can export public
part to public.snk, but you never can export private-only part via sn.exe.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/377#issuecomment-27765671
.

[maximpashuk]

One more thing.

Please do not change name of file (Nest.Signed.dll) because ilmerge also changes the name of assembly, this will broke the references, keep NEST.dll
Just set output folder another than folder with originals live (create it first of course).

[maximpashuk]

You know, probably best solution for you will not use ilmerge at all.

If you familiar with msbuild you can define 2 compile targets: Compile and CompileWithStrongName

In target CompileWithAStrongName you can pass parameters to msbuild task "SignAssembly=true" and "AssemblyOriginatorKeyFile=fullkey.snk"

This will produce a signed versions.

here is the old, but useful link about it
http://blogs.msdn.com/b/msbuild/archive/2005/09/26/474079.aspx

[Mpdreamz]

I fixed the build files to properly sign the dlls, 0.11.8.0 will have properly signed dlls. Thanks for making me aware of this @maximpashuk 👍