5

Every now and then I see a sample project on the network which contains a .snk file used for signing the compilation results with a strong name.

AFAIK this is plain wrong - once a .snk file is disclosed anyone can produce an assembly that can be used to replace an assembly shipped by the original code supplier but now containing malicious code. I suppose that people shipping .snk files don't treat that risk seriously and just ship the file because otherwise the project wouldn't compile off-the-shelf.

Is there any reason for shipping the .snk file except that "convenience"?

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979

3 Answers3

3

A very valid question. I for my part do not ship the SNK file but do provide instructions how to produce one yourself and make the required changes (to enable InternalsVisibleTo for instance).

I think that the current practice has been pushed my Microsoft with the changes in the SNK handling starting with VS2005. Using a key container requires a manual edit of the CSPROJ file with an undocumented MSBUILD item KeyContainerName... the default of VS is to copy the SNK into the project directory, which is convenient but wrong IMHO.

Lucero
  • 59,176
  • 9
  • 122
  • 152
2

The only reason I can think of, is to allow a drop-in replacement for your dll...

Of course, normally I'd say "don't sign your dll if you want drop-in replacements." but if it's installed in the GAC signing is a pre-requisite. (or was, last time I knew).

So allowing replacements for your dll that is installed in the GAC. Is the only rational reason I can think of...

Massif
  • 4,327
  • 23
  • 25
  • Strong names are a must IMHO: you cannot sign an assembly which references non-signed assemblies, and therefore this creates a chain of unsigned assemblies. On unsigned assemblies, the version is not checked either AFAIK, which makes them very unsafe to use because you're opening the door to DLL hell again. – Lucero Jan 31 '11 at 12:17
  • Fair enough, but no reason to ship the snk file, unless you want to allow people to use replace a with no modification to the client. Of course, versioning becomes another issue at this point. – Massif Jan 31 '11 at 12:20
  • I completely agree with that, shipping the SNK is a no-go for me (see my answer for details). – Lucero Jan 31 '11 at 12:23
  • +1, but... This looks like a typical "how to shoot yourself in the foot" idea. The idea of a drop-in replacement for assemblies in the GAC with an assembly created by an *unknown third party* sounds insane. I hope not many people do this. – sharptooth Feb 02 '11 at 10:06
1

At least, I can't see a reason to ship both, the private and the public keypair together. If you need to ship source code you could alternatively use a .pfx which has improved security through the password you'll need to sign the assembly.

Anyhow, it seems to be common practice (bad practice) in a lot of open source projects to add the .snk file to the source control. So a very good question!

Martin Buberl
  • 45,844
  • 25
  • 100
  • 144