¿Proyectos.NET OpenSource y ensamblajes nombrados fuertes?
open-source strongname (3)
Actualmente estoy pensando en abrir un proyecto mío y estoy en el proceso de preparar el código fuente y la estructura del proyecto para que se lance al público. Ahora tengo una pregunta: ¿cómo debo manejar la clave de firma para mis ensamblajes? ¿Debo crear una nueva clave para la versión de código abierto y publicarla junto con los otros archivos en el repositorio de SVN? ¿Debo dejar la clave y todos los que quieran compilar el código deberían generar su propia clave?
Como manejas esto? Me siento un poco incómodo con la publicación de una clave de firma para el público.
No lanzaría la clave públicamente. El objetivo de tener una asamblea firmada es que las personas puedan confiar en que eres el único que tocó el binario, por lo que si se agrega un código ilegítimo, la firma se desactiva y las personas saben que no deben confiar en el ensamblaje.
La firma de ensamblajes lo protege de otras personas que agregan código "malo" a su código binario y pretende que es un lanzamiento legítimo.
No sueltes la tecla.
DEBERÍA sentirse incómodo al liberar una clave de firma para el público. No es la firma del proyecto . Es SU firma . La integridad de la firma en el binario se mantiene solo si mantiene su clave secreta. La liberación de la clave subvierte el significado y la intención de los ensambles firmados y los nombres fuertes, lo que introduce nuevas posibilidades de errores y, por lo tanto, hace que cada sistema sea menos confiable. No sueltes la tecla .
Para DotNetZip , no lanzo la clave. Pero aquí está el punto clave: la clave no pertenece al proyecto; es mi llave Muchas personas han pedido la clave para que puedan volver a generar el binario firmado, pero eso no tiene sentido. Uso la tecla para firmar más que DotNetZip. Cualquier binario firmado con esa clave está firmado por mí, por definición. Cualquier dos binarios que tengan el mismo nombre fuerte usando mi clave, están garantizados para ser idénticos. La liberación de claves elimina esas garantías y frustra el propósito completo de los nombres fuertes y la seguridad que los rodea.
Imagine que los desarrolladores eligen sus propios números de versión y vuelven a firmar un código binario modificado con mi clave. Ahora el mundo tendría 2 ensambles con el mismo nombre fuerte, pero con diferentes contenidos.
Imagínese si pudiera firmar cualquier ensamblaje con SU llave. Si liberaste tu llave, podría agregar cualquier código que me gustara -incluso código malicioso- y luego firmarlo, y subrepticiamente reemplazar cualquier "bueno" binario firmado con uno "malo". Nadie sería capaz de notar la diferencia.
Esto está descompuesto. Compartir claves libremente elimina cualquier ventaja de usar ensambles firmados.
Si las personas desean modificar el código en un proyecto y luego volver a utilizar la versión modificada en un ensamblado con un nombre fuerte, pueden firmar la versión modificada con su propia clave. No es dificil.
Para los Protocolos de Protocolo , lanzo la clave. Sí, eso significa que las personas no pueden confiar en que es el binario original, pero hace que la vida sea mucho más fácil para cualquiera que desee modificar un poco el código, reconstruirlo y aún así poder usarlo desde otro ensamblado firmado.
Si alguien realmente quiere una versión de Protocol Buffers en la que puede confiar que es definitivamente la legítima construida con el código de GitHub, puede construirla fácilmente desde la fuente en la que confía.
Sin embargo, ciertamente puedo verlo desde ambos lados. Creo que si estuviera escribiendo un proyecto de código abierto que girara en torno a la seguridad podría ser una cuestión diferente.