with - .NET: ¿Deben los ejecutables ser firmados por un nombre fuerte? ¿Qué pasa con las DLL privadas?
strong name tool (4)
En mi opinión, estos son los beneficios de la firma de nombre fuerte en esta situación:
- Evita que un atacante reemplace una DLL con una firmada usando otra clave (o que no tenga ninguna firma), sin reemplazar también el EXE (ya que el EXE contiene una referencia que incluye la clave pública).
- Impide que un atacante modifique un ensamblaje mientras retiene la clave existente (ya que esto hará que la verificación de la firma falle). Sin embargo, tenga en cuenta que a partir de .NET 3.5 SP1, la verificación de firmas en esta situación está deshabilitada de forma predeterminada .
- Podría evitar que la aplicación se ejecute con versiones de ensamblajes no coincidentes: si una DLL se ha reemplazado incorrectamente debido a un error de implementación, la aplicación no podrá cargarla en lugar de tratar de usar una versión incorrecta (potencialmente incompatible).
- Evita las advertencias de FxCop.
Y los inconvenientes de firmar (creo que esto es a lo que se refiere el artículo vinculado):
- Reemplazar una DLL con una versión más nueva compatible (para corregir un error, por ejemplo) requiere reemplazar el EXE.
- En las versiones .NET <3.5 SP1, los ensamblajes con nombre seguro tardan más en cargarse debido a la verificación de la firma.
- Las DLL con nombre seguro también tardan más en cargarse porque el cargador realiza una búsqueda (inútil en esta situación) de la GAC antes de buscar localmente.
Parece una pena que la elección sea una denominación segura (y, por lo tanto, que requiera referencias para que coincidan con una clave exacta y una versión exacta), o que no sea una denominación segura (y que no requiera que ambas coincidan). Si fuera posible requerir una clave pero no una versión en particular, tal vez sería posible obtener los primeros 2 beneficios de firmar sin obtener también el primer inconveniente. ¿Tal vez esto sea posible aplicando un nombre seguro y luego lidiando con el problema de las versiones usando app.config?
Mi aplicación consta de tres ensamblajes: un solo EXE que hace referencia a un par de DLL. Las DLL son privadas para mi aplicación, solo las utiliza este ejecutable.
¿Deberían estos conjuntos tener un nombre fuerte?
FxCop sugiere que deberían, para todos los ensamblajes que produce actualmente:
CA2210: Firme <ensamblaje> con una clave de nombre seguro.
Sin embargo, este consejo dice:
En general, debe evitar los ensamblajes EXE de aplicaciones de nombres fuertes.
y
es posible que desee evitar componentes de nombres fuertes que sean privados para su aplicación.
¿Debo dar un nombre fuerte a estas asambleas? ¿Cuáles son los beneficios de hacerlo (o no hacerlo) en este caso?
Editar:
Al observar varias aplicaciones con una estructura similar, parece que no hay consenso sobre este tema. Los binarios de Paint.NET y Crack.NET no tienen Crack.NET fuertes, mientras que los de .NET Reflector y Snoop son.
Curiosamente, con el conjunto de expresiones de Microsoft, Microsoft ha adoptado este último enfoque: en Expression Blend, por ejemplo, han elegido el signo de fuerte nombre Blend.exe y las DLL que lo acompañan (como Microsoft.Expression.Blend.dll).
Parece que es poco probable que reciba una respuesta simple a mi primera pregunta: "¿Debo dar un nombre fuerte a estas asambleas?". Sin embargo, mi segunda pregunta sigue en pie:
¿Hay beneficios para los binarios de firmas de nombre fuerte en esta situación? O bien, ¿hay algún beneficio por no hacerlo?
Edición 2:
Si no hay razones abrumadoras para ir de cualquier manera, me inclino a darle a mis asambleas un nombre sólido. Por lo tanto, me gustaría saber si alguien puede ampliar esto (desde el primer enlace):
"los nombres fuertes pueden hacer que sea más difícil administrar las dependencias y agregar una sobrecarga innecesaria para los componentes privados".
La firma de ensamblajes garantiza que los ensamblajes no se modifiquen después de la compilación. Y mientras usted sea el único propietario de la clave privada, nadie podrá renunciar al ensamblaje con su clave.
Claro, esto no es una protección absoluta. Un pirata informático puede modificar los ensamblajes y eliminar las firmas de nombre seguro (y las referencias) de todos los ensamblajes. Estas asambleas también funcionarían.
Pero en tal caso, puede decir que usted no realiza las modificaciones.
Los conjuntos de nombres sólidos SOLO garantizan la compatibilidad de versiones. Esto no es lo mismo que confiar en el montaje.
En otras palabras, el "nombre seguro" SOLAMENTE se refiere al binario de ensamblaje exacto en combinación con el número de versión en uso en el momento de la compilación.
Si GAC esos ensamblajes, entonces el CLR solo lo verificará una vez. En el momento en que la asamblea es gac''d. Esto puede resultar en una mejora del rendimiento. Sin embargo, mi experiencia ha demostrado que es mínima.
Un ensamblado con nombre seguro puede reemplazarse con uno que no tiene nombre fuerte; lo que trae a colación la parte acerca de la denominación fuerte NO es ningún tipo de característica de seguridad.
Mi opinión personal es que el nivel de dolor asociado con ellos no justifica su uso. El dolor es cómo se atornillan con herramientas de prueba automatizadas.
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5054496.html
Si firma un ensamblaje, cualquier ensamblaje al que se haga referencia se expone públicamente y también debe estar firmado. De lo contrario obtendrá un error de compilación por una buena razón.
Creo que el uso principal para nombrar un ensamblaje con fuerza es introducirlo en el GAC.
No veo la necesidad de nombrar fuerte un exe.
solo mis 2 pesos ....