Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
maximpashuk opened this issue Nov 5, 2013 · 6 comments

Comments

@maximpashuk
Copy link

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
Copy link
Member

Mpdreamz commented Nov 5, 2013

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
Copy link
Author

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
Copy link
Member

Mpdreamz commented Nov 5, 2013

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 [email protected]:

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
Copy link
Author

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
Copy link
Author

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
Copy link
Member

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 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants