ubicación del archivo .snk y administración de él

Question

Actualmente estoy configurando mis bibliotecas .net para que firmen con una clave fuertemente tipada. Estoy usando el archivo .snk para firmar mi dll por solución. Entonces, para cada solución, tiene su propio archivo .snk. ¿Es esta la práctica correcta? Por ejemplo, tengo una biblioteca de clases que genera varias dll diferentes de cada uno de los proyectos dentro de la solución, cada una de ellas está firmada con la clave .snk.

Mi pregunta se refiere al almacenamiento de la clave en el control de fuente. A medida que ramifico mi código para cada lanzamiento. En caso de que la clave:

A. existe fuera de las ramas y no ser ramificado - asegurar su la misma clave para cada rama B. existen dentro de la rama, sino ser el mismo para cada rama C. existir dentro de la rama y el cambio para cada rama D. Otro (especifique)

Sugerencias, por favor?

También es una buena práctica firmar los dll colocando lo siguiente en el archivo SolutionInfo o ¿hay alguna alternativa?

[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")] 

Answer 1

Dependiendo de la aplicación específica, es normalmente mejor manera de mantener el archivo de clave .snk en la rama que está trabajando.

El caso de uso es: estamos cambiando nuestra clave de firma de ensamblaje entre v1.0 y v2.0. Todavía querría poder mantener el código actual en la línea externa, mientras desarrolla contra la clave correcta en su (s) rama (s).

En segundo lugar, (y esta es solo una práctica recomendada, no necesaria según su situación, por ejemplo, qué tan bien confía en los demás desarrolladores) el archivo .snk que mantiene en control de fuente solo debe contener una clave pública, y la solución debe configurarse para retrasar la señal solamente.

Esto impide la difusión de su clave privada, que debe almacenarse protegida en el servidor de compilación (muy probablemente en el administrador de claves de Windows) y utilizada durante las compilaciones de "liberación" para firmar completamente los ensamblajes. Si no tiene un servidor de compilación, es una buena práctica tener a 1 o 2 personas a las que se haya confiado la clave privada, en cuyo punto pueden firmar los ensamblados con sn.exe después de la compilación. Un simple script de shell o un archivo por lotes puede automatizar este proceso.

Por último, y sólo si elige retrasar la señal, tendrá que añadir una entrada en la lista de verificación NET (sn.exe -Vr *,<publicKeyToken>) en todas las estaciones de trabajo de desarrolladores que se ejecutará/debug las asambleas de retardo firmado. Según el objetivo de la plataforma, deberá ejecutarlo en las versiones de 32 y 64 bits del símbolo del sistema de VS.

Espero que ayude.

Answer 2

Hay dos estrategias básicas. El primero es adecuado para empresas muy grandes que necesitan temer a alguien más que sustituya sus ensamblajes con fines maliciosos. Los gustos de Microsoft, Adobe u Oracle. Nadie más que un pequeño grupo de ingenieros de construcción confiables tiene acceso a la clave, el código se desarrolla y prueba mediante la firma de retraso.

La otra es para todos los demás, solo tiene que firmar el ensamblaje para ingresarlo en el GAC o porque lo envía a un segundo interlocutor que podría querer ponerlo en el GAC. La clave real que usas no importa ni tienes que ponerla en una gran bóveda. Simplemente use Project + Properties, pestaña Firma. Genera una clave y compruébalo junto con el proyecto.