¿Cuál es la forma recomendada de administrar un par de claves de nombre seguro para un proyecto de código abierto?

Question

Administro un proyecto de código abierto y me gustaría firmar los binarios que se lanzan en el paquete binario del proyecto. Uso los archivos de Visual Studio csproj y sln para administrar y crear mi proyecto, y también distribuir estos archivos como parte de los paquetes fuente del proyecto.

¿Cómo puedo firmar los archivos binarios producidos de mi compilación y no tener que distribuir el archivo de par de claves snk? Si uso Visual Studio para firmar los ensamblajes, cada archivo de proyecto ahora necesita una copia del par de claves para poder compilar. No me siento cómodo distribuyendo el par de claves, incluso si está protegido por contraseña.

Editar:

Otra advertencia es que algunas asambleas en el proyecto amigo concesión de acceso a través InternalsVisibleToAttribute, y construir esos amigos a través de una referencia de proyecto. En consecuencia, dichos ensambles necesitan usar un nombre fuerte cuando se refieren a un ensamble firmado. Sin embargo, si el par de claves no está distribuido, ¿cómo pueden los usuarios finales construir las fuentes y mantener las relaciones del proyecto? Si se utiliza un archivo de par de claves temporal, ¿no cambiará el token de clave pública de los ensamblados firmados, rompiendo las referencias InternalsVisibleToAttribute?

Answer 1

Sharptooth's solution funciona bien si las únicas referencias de ensamblaje en el código son las codificadas en los archivos de proyecto. Si su proyecto se refiere a otros ensamblajes a través de InternalsVisibleToAttribute u otros medios donde se requiere una cadena de nombres fuertes, entonces no es factible construir las fuentes de repositorio con una clave temporal. Al hacerlo, se cambiarán las referencias de clave pública que están presentes en las cadenas de nombres fuertes y se romperá el código.

Este es el caso en mi aplicación, así que tuve que adoptar un enfoque diferente.

Básicamente creé una copia de los archivos sln y csproj en una jerarquía de carpetas separada y modifiqué los archivos csproj de la siguiente manera.

• Transformó todas las referencias de archivos a enlaces, apuntando a las fuentes originales.
• Copié y modifiqué cada archivo AssemblyInfo.cs para que contenga los usos de InternalsVisibleToAttribute con un nombre seguro.
• Modified cada archivo csproj para que el snk referencia de archivo es una ruta relativa (elimina la necesidad de copiar el archivo snk a cada proyecto)

por primera vez hizo todo esto de forma manual, pero luego se dio cuenta de que esto puede ser automatizado de una manera directa. El primero y el tercer pasos se pueden implementar con un XSLT, mientras que el segundo paso se puede implementar con una función de búsqueda/reemplazo de expresiones regulares.

Como necesito mantener dos soluciones ahora, tiene sentido automatizar esta tarea para evitar futuros dolores de cabeza.

Las fuentes en el repositorio no crean ensamblados con nombres fuertes, lo cual está bien, ya que no me gustaría imponer ninguna restricción de compilación o procesos a los usuarios finales.

Answer 2

No debe distribuir el par de llaves. El nombre fuerte es para verificar que la nueva versión del ensamblaje proviene del mismo editor.

Si otro desarrollador desea realizar una bifurcación de su proyecto, generará su propio par de llaves y mostrará efectivamente que su versión no es suya, de modo que otros ensambles que dependen del suyo ya no se cargarán a menos que se vuelvan a compilar. Eso no siempre es conveniente, pero lo protege de alguien que emite una versión maliciosa del ensamblaje y lo distribuye silenciosamente.