Signing Assemblies with Key File (snk) Practices

[Joel Leong]

I wish to know the industrial practices for signing
assemblies with key files.

I genereted a key file to sign my assemblies.

Should I sign all my assemblies with a single key files
or I shall generate one key file for each assembly?

Perhaps, I should generate a key file per group of
related assemblies?

Please advice

 

[Mona]

Hi Joel,

All assemblies you produce can use the same public and private keys as long
as the assemblies
have unique friendly text names.

Next, you need to associate the 1,024-bit public key with an assembly. You
do this by telling the
compiler to read the contents of a key file, extract the public key from the
key file, and place the
public key into the definition of the assembly's identity. In effect, this
makes the public key an
extension of the friendly text name of the assembly. This also makes the
assembly name globally
unique because no other developer will be using the same 1,024-bit public
key as part of their assemblies' name.

You can know more about key files and how to generate them on the following
link:
[/keyfile]
http://msdn.microsoft.com/library/d...7/html/valrfassemblykeyfilespecifykeyfile.asp


HTH

Mona

 

[Nick Malik [Microsoft]]

I would recommend that you generate a single key file for each solution
where the key files are used by the projects within the solution.
If you have assemblies that you re-use across projects:
There are two ways to reuse a project:
a) to include the code in another solution
b) to reference the compiled dll

if you are using (a) in your solutions, then I use the following logic:
a.1) if all of your projects are under a single source tree, then place
the key file closer to the root of the source tree, so that it is in a
directory that is a common ancestor to all of your source directories. That
way, your reference to the key file can still be a relative reference.
a.2) if your shared library is not in a common source tree but you still
intend to share source, place the key file in the same directory as the
AssemblyInfo file.

if you are using (b) in your solutions:
b.1) if all of the projects using the same key file are related, then
use (a.1).
b.2) If the projects are unrelated, use (a.2)

In your assemblyinfo.cs file, ALWAYS use a relative path location. I know
it is a hassle to put in a filename like
"..\..\..\..\..\..\..\..\..\keyfile.snk" However, doing so will allow the
code to be compiled on any developer's workstation simply by fetching the
entire source tree from version control. (this includes for build
machines). If you code "C:\a\b\c\keyfile.snk" and get the source tree onto
the D: drive of a build machine, none of your projects will compile.
Depending on what was on that machine before the compile was initiatited,
the error messages that appear can be anywhere from small (a few lines
pointing at the assemblyinfo file) to severe (hundreds of lines of errors
because an obsolete version of one or more common dlls was on the target
machine).

do not share key files between projects.

Note that key files are used to sign assemblies for the GAC. If you would
also like to sign controls for download to IE, you will need a different set
of procedures. The procedures above are for signing for the GAC and nothing
more.

HTH
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Richard Grimes [MVP]]

Joel Leong wrote:

I talk about signing files on the third section of my fusion workshop
(http://www.grimes.demon.co.uk/workshops/fusionWS.htm).

I wish to know the industrial practices for signing
assemblies with key files.

I genereted a key file to sign my assemblies.

Should I sign all my assemblies with a single key files
or I shall generate one key file for each assembly?

Perhaps, I should generate a key file per group of
related assemblies?

Look at the purpose for the key pair:

1) gives your assemblies a strong name
2) associates the assemblies as coming from the same publisher
3) signs your assemblies to prevent tampering

The use in the strong is that the key is unique and hence the assembly name
is unique, so if another assembly uses your library Fusion knows that it
should load *exactly* the right version, no other version will do. Since you
generate the key pair, the pair is associated with you. This does not say
who you are (a vertificate will do that) but it does say that if you
published assembly X with a key, and the user has an assembly Y signed with
the same key, then Y was also written by you. This is important because your
users could decide that they want to trust all assemblies from you and so
this is quite simple to do: trust all assembleis with the same public key.
When your assembly is signed a hash of the assembly is signed with the
private key and stored in the assembly along with the public key, so when
the assembly is loaded the hash is generated again and compared with the
hash stored in the assembly after it is decrypted with the publis key. If
the two hashes are different then the assembly has been tampered with since
it was published, and so it is not loaded.

So my advice is to have a *single* key pair for *all* the assemblies you
write. Keep that key pair safe (use delay signing if necessary
http://www.grimes.demon.co.uk/workshops/fusWSThree.htm#Example_3_8). That
way a user will be able to trust all of your assemblies. If you have lots
and lots of keys (one key per application, or a key for a group of
assemblies) then the keys are no longer useful as a way to identify the
publisher.

Richard