2009-05-13 14 views

Respuesta

8

le sugiero que lea Strong name assemblies can keep you out of DLL Hell:

asambleas nombre seguro permiten a los desarrolladores para simplificar componentes actualizaciones y evitar la infame DLL Infierno. Obtenga información acerca de la anatomía de los nombres fuertes de y vea cómo puede usar para garantizar la compatibilidad de la versión y la seguridad en sus aplicaciones .NET.

También vea this article para obtener un tutorial rápido sobre cómo dar un nombre seguro a un conjunto.

+3

El primer enlace está roto –

2

También se puede utilizar para garantizar que el conjunto no se manipule ya que se ha liberado del editor original.

+1

Pero le falta una forma de verificar el editor original. Para eso, debería usar una tecnología como AuthentiCode además. Sin embargo, el objetivo principal es crear nombres únicos ("fuertes") para identificar una versión específica de un ensamblado (para solucionar los problemas de 'DLL Hell' http://msdn.microsoft.com/en-us/library/ms811694 .aspx) –

+0

@divo: Ciertamente. Esto se menciona en la respuesta de Andrew. No vi la necesidad de duplicar. Solo quería agregar esta posibilidad. He mencionado este hecho en detalle en esta respuesta: http://stackoverflow.com/questions/369248/can-strong-naming-an-assembly-be-used-to-verify-the-assembly-author/369268#369268 –

1

Escribí una respuesta larga que describe la manera en que nombrar un ensamblaje impide que un tercero altere el ensamblaje como respuesta a este question. Puede ser útil si quieres saber cómo y por qué.

+1

Eso es verdad. Sin embargo, este no ha sido el aspecto principal cuando se diseñó un nombre fuerte. A los nombres fuertes les faltan características importantes como autenticación y revocación del editor. Si se desea una distribución a prueba de manipulaciones de sus ensamblajes, es mucho mejor confiar en certificados digitales (como Authenticode). –

0

Creo que una de las características importantes es evitar el secuestro de DLL (o lo que sea que se llame) debido a posibles problemas de permisos débiles.

Supongamos que una de las DLL en su aplicación puede ser escrita por "todos" en ese caso alguien puede simplemente modificarla y cuando un privilegiado alto ejecuta el atacante de la aplicación .NET puede elevar sus privilegios.

Esto es bastante bueno porque en el mundo real puede ver estos ataques contra aplicaciones tales como antivirus y otras aplicaciones complejas que dependen de varias DLL en diferentes ubicaciones.

Cuestiones relacionadas