c# - una - ¿Quién debe poseer la clave privada utilizada para firmar un ensamblado.NET cuando su proyecto es de código abierto?
la signatura del nombre seguro no es válida para este ensamblado stdole dll (7)
Más específicamente, un ensamblaje de biblioteca de clases. Mis pensamientos iniciales:
- Haga que algunos administradores designados hagan toda la firma de la asamblea. Pero luego, cuando se escriben correcciones de errores y se escriben nuevas versiones, los binarios dependerían en última instancia de que estén cerca (incluso si se trata de un pequeño cambio por razones privadas).
- La clave podría estar disponible públicamente. Pero eso va en contra de las prácticas de criptografía de clave pública y pierde la ventaja de la confianza y la identidad.
- Permitir a los desarrolladores finales y distribuidores firmarlo con sus propias claves. Pero luego pierde la modularización, ya que cada nueva firma lo hace incompatible con algunas de las otras versiones.
Claro, simplemente no podrías firmar la asamblea. Pero si otro proyecto que requiere que su ensamblaje esté firmado hace referencia a su biblioteca, obtendrá un error de compilación.
Almacene la clave privada fuera de la raíz de control de origen pero se hace referencia con una ruta relativa. De esa manera otros pueden hacer construcciones usando su propia clave. Estarán firmes pero no serán construcciones oficiales.
Configura una compilación automática que tenga el árbol fuente completo y la clave privada. La compilación automática puede realizar construcciones oficiales firmadas que pueden publicarse todas las noches o lo que sea. De ese modo, la creación oficial de compilaciones es automática, por lo que la persona autorizada que posee la clave privada no necesariamente tiene que participar (aunque debe tener algún mecanismo para validar los parches aportados por la comunidad antes de incluirlos en una compilación oficial, pero ese es un problema aparte). De Verdad).
En Open Source, la "fuente" está abierta. Los binarios se proporcionan generalmente sólo para productos.
La fuente no necesita estar firmada, si el binario está firmado, el generador del binario también es el propietario de la clave secreta (que se mantendrá secreta).
Hasta donde puedo recordar, nunca me he encontrado con un proyecto de código abierto firmado. Si lo necesitaba firmado por alguna razón, lo firmé yo mismo. Realmente no puedo ver una ventaja de firmar un ensamblaje como tal. Si está preocupado por la firma de la versión binaria precompilada, entonces diría que solo la gestión de proyectos debería tener esa clave. Una persona que crea un proyecto firmado debe ser capaz de agregar el código fuente a su proyecto, o crear la firma necesaria del proyecto y compilarla por sí misma.
La denominación fuerte no tiene la intención de proporcionar autenticidad, validación, protección ni nada por el estilo. Su único propósito es proporcionar una ID única para un ensamblaje o una serie de ensamblajes. Esto es para que pueda tener muchos ensamblajes llamados "Biblioteca" en el GAC, y cuando su aplicación le pide al tiempo de ejecución que cargue "Biblioteca", el sistema sabe que esto significa su ensamblaje de "Biblioteca" y no el de otra persona.
En vista de esto, simplemente incluiría la clave de nombre seguro en el árbol de origen. Si, por algún motivo, su proyecto desea proporcionar autenticidad o cualquiera de esas otras cosas, entonces es probable que desee la firma de Authenticode, que no es gratuita y realmente es probablemente innecesaria para un proyecto de código abierto. Si decide ir por ese camino y se pregunta quién debe ser el propietario de la clave de firma de código, eso se convierte más en una cuestión política.
La pregunta realmente gira en torno a quién decide qué es un lanzamiento, ¿no es así? Si es así, creo que las liberaciones deben firmarse con una clave personal de la que realmente es responsable de la liberación. Si hay varias personas responsables de crear lanzamientos, no hay nada de malo en que compartan la clave, a excepción de los mayores riesgos de tener que revocar / volver a emitir la clave si uno de los miembros de este grupo se retira.
En un ámbito más amplio, uno tiene que admitir, que .net no se ocupa realmente de reutilizar los conjuntos entre varias aplicaciones instaladas. ¡Mira en tu carpeta SxS! Así que otra manera sería siempre que el distribuidor de la asamblea lo firme con su propia llave. por ejemplo, si un proyecto utiliza log4net, debe firmar el ensamblaje de log4net con su propia clave para asumir la responsabilidad de su contenido.
Por mi parte, no me importaría si la mayoría de los proyectos que probablemente vayan a usar como referencia en lugar de editar y volver a compilar ofrezcan una versión "firmada" de la dll. Eso ayudaría a confiar en una referencia a un .dll existente más rápido que verificar el código y compilar el suyo propio.
En muchos de los proyectos de código abierto, hay una especie de "padre" del esfuerzo, piense en Linus o incluso en John Gruber, por ejemplo. Estas personas podrían tener la clave o distribuirla a un administrador de confianza para firmar las principales publicaciones.
Recientemente he encontrado el mismo problema en un proyecto de código abierto que mantengo. Aquí es cómo abordé este problema:
- Las fuentes siempre están disponibles para su descarga a través del repositorio, pero una versión consistirá en una instantánea de las fuentes, más una versión compilada.
- Antes de hacer que la versión compilada esté disponible, firmo los ensamblados con mi clave privada.
Entonces, en su caso, quien esté preparando el lanzamiento debe poseer la clave. No hay necesidad de que los desarrolladores de bibliotecas lo sepan en absoluto.
Si los usuarios finales desean recompilar y firmar con sus propias claves, está bien. Puedes distinguir entre los binarios tuyos y otros comparando la clave pública que está presente en los ensamblados firmados. Haga que la clave pública esté disponible y otros pueden hacer lo mismo.
La gestión de este proceso se vuelve un poco incómoda cuando se utiliza InternalsVisibleToAttribute para referirse a ensamblajes de nombre seguro. Puedes leer acerca de cómo abordé ese problema here .