¿Hay algún problema con NO firmar un ensamblado .NET?

Uno de mis colegas está muy interesado en firmar asambleas. Literalmente intenta firmar cualquier cosa. Incluso cuando usamos ensamblados de Microsoft que no están firmados, él tomará el código fuente, lo firmará y luego pedirá a otros desarrolladores que usen su copia.

Puedo entender la idea básica detrás de la firma de una asamblea: asegurar que una asamblea en particular no sea comprometida por un hacker poco fiable. Entonces, si somos una empresa de desarrollo de software, deberíamos firmar nuestro ensamblaje antes de lanzar alguna biblioteca .NET a nuestros clientes.

Sin embargo, aquí desarrollamos principalmente aplicaciones web para nuestro propio uso, y no veo el sentido de firmar cada ensamblado que usamos.

¿Me estoy perdiendo de algo?

Firmar ensamblados que se utilizan en un entorno de confianza me parece una exageración.

Un punto interesante sobre los ensamblajes firmados es que son un poco más lentos de cargar que los ensamblados sin firmar, ya que deben verificarse criptográficamente.

Para firmar una asamblea, todas las asambleas de las que dependa también deben estar firmadas. Supongo que esto contribuye al deseo de su colega de firmar todo, el compilador lo exige.

EDITAR Desde que escribí esta respuesta, puede ver que tanto el campo a favor como en contra tienen un apoyo aproximadamente equivalente. Claramente no hay una respuesta correcta aquí.

Sin embargo, el punto que obligó a esta edición es que hoy en día tomamos tantas bibliotecas de código abierto de NuGet, y muchas de ellas no están firmadas en absoluto. Si deseaba firmar su ensamblado, también necesitaría firmar todas las dependencias. Muchas de las bibliotecas de código abierto que están firmadas tienen las claves privadas utilizadas para firmar disponibles públicamente en sus repositorios de origen.

Como ocurre con todo, hay que hacer concesiones. En mi experiencia de trabajo en entornos privados, los beneficios de firmar son principalmente teóricos (o académicos, como menciona @ user289100 ), a menos que le preocupe que las agencias gubernamentales modifiquen su código, en cuyo caso debe ser paranoico acerca de tantos niveles de su infraestructura, esa firma parecería una pequeña cantidad de esfuerzo. De lo contrario, la cantidad de desafíos que surgen al tener que firmar todo no parece valer la pena. Sin embargo, su entorno puede tener diferentes requisitos, ¡o puede ser un masoquista!

Consulte también la respuesta de Teun D para obtener información sobre los desafíos relacionados con el control de versiones de ensamblados cuando se usan nombres seguros.

He aprovechado las asambleas no firmadas para solucionar problemas antes y en entornos académicos mostrarle a la gente por qué es importante. Reemplacé un archivo DLL que no estaba firmado (nuevamente en un entorno académico) con uno que hice con el mismo nombre, las mismas firmas, y usé .NET Reflector para copiar y pegar el código original, pero en el mío envié por correo electrónico nombres de usuario y contraseñas que se pasaban antes de llamar al código 'real'.

Si está firmado, puede hacer una coincidencia de firma, pero no reemplazarla. Al contrario de lo que dice Zippy, habrá un error de cumplimiento en tiempo de ejecución.

Firmar asambleas nunca es una exageración. Tarda 30 segundos. Es como decir que cerrar las puertas con llave es excesivo si vives en el campo. Si quieres apostar con tus pertenencias, adelante, déjala abierta. Solo se necesita una brecha de seguridad para ser despedido. Solo se necesitan 30 segundos para firmar una asamblea y no hay razones comerciales para no hacerlo. Los impactos en el rendimiento son insignificantes.

Un punto adicional: la firma de sus ensamblajes rompe la compatibilidad con versiones anteriores. Todas sus referencias comienzan a incluir números de versión y las versiones con otros números de versión se consideran no compatibles. Esto dificulta la actualización a versiones más nuevas de ensamblajes distribuidos.

En mi opinión, solo debería firmar con código los ensamblados si ve alguna ganancia concreta de ello:

• si implementa en entornos donde personas que no son de confianza pueden tocar sus ensamblajes
• en determinados modelos de complementos, en los que desee utilizar el certificado como prueba para actualizar la confianza
• si su código debe poder llamarse desde otro código firmado (un proyecto como, digamos log4net, firma justificadamente su código para que sea ampliamente utilizable; se equivocaron enormemente en la compatibilidad al perder su clave secreta hace unos años, otro riesgo de la firma de código) .
• si desea implementar en el GAC

¿Su colega le ha dado alguna indicación de por qué le gusta firmar asambleas? Una ventaja de la firma que aún no se ha discutido aquí es que solo los ensamblados firmados se pueden colocar en el GAC (es decir, se pueden compartir entre los procesos administrados), pero las desventajas parecen superar las ventajas desde mi perspectiva (ciertamente inexperta).

Su anécdota sobre el código de Microsoft autofirmado me parece particularmente sospechosa. Si MS no firmó el código, probablemente haya una razón, ¿verdad? Y al firmarlo, asume la responsabilidad por él cuando no lo escribió: otra oportunidad para que el futuro lo muerda.

Otra cosa acerca de firmar una asamblea es que uno no puede inyectar una incorrecta en lugar de la suya (también, usted mismo por un accidente). Por ejemplo, si crea un programa que hace referencia a un ensamblado Foo.dll, versión 1.0, alguien puede crear un ensamblado, con la misma versión, y reemplazar el suyo, cuando firme su biblioteca, no será posible (en al menos no creo que sea fácilmente posible).

Las firmas solo son necesarias si las asambleas se colocan en el GAC, nada más. Las asambleas firmadas no impiden que alguien se meta con ellas. Un pirata informático aún puede quitar la firma y cualquier otro código que verifique la firma.

Estoy de acuerdo en que parece un desperdicio. Es realmente necesario para asegurarse de que el archivo sea lo que usted cree que es (y no ha sido manipulado). Pero si confía en los límites de su propia seguridad de red y servidor web, entonces firmar sus ensamblajes web parece un paso redundante.

Pero tal vez esa sea mi experiencia en la pequeña empresa hablando. Si está hablando de un sitio web de banca en línea de misión crítica, cierre la sesión.

Piense en hacerlo si va a enviar algo y / o tiene una razón para hacerlo. En cualquier otro caso, es una molestia. Le preguntaría a tu compañero de trabajo qué es lo que realmente obtiene al hacer esto.

Me he encontrado con ensamblajes firmados antes y es un dolor en la parte posterior, especialmente cuando se considera la cantidad de personas que tienen poco o ningún conocimiento sobre la firma de ensamblajes, para qué sirve y cómo hacerlo. Es solo otra cosa de la que no debería tener que preocuparse a menos que sea absolutamente necesario.

Debe firmar su ensamblado cuando se usa en un XBAP ClickOnce de implementación desde la web .

Además, todos los ensamblajes referenciados también deberán estar firmados.

Firmamos nuestros ensamblajes porque hay ocasiones en las que obtenemos errores como los siguientes (este es de prueba, pero puede ocurrir al ejecutar la aplicación):

System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

TearDown : System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Descubrimos que Visual Studio se equivoca a veces y ejecuta código antiguo .

Si desea un error si está ejecutando un código antiguo, firme sus ensamblajes.

Si está escribiendo un paquete nuget , firme sus ensamblajes . Los ensamblados sin firmar son incómodos para nosotros que queremos asegurarnos de que estamos ejecutando la última versión de nuestro código. No puedo arreglar Visual Studio . Todo lo que puedo hacer es detectar que Visual Studio se equivocó. Así que, por favor, firme sus ensamblajes nuget .