Dans certains codes C # que j'ai repris (dans Visual Studio 2005), j'ai remarqué que les assemblys sont tous signés avec le même .snkfichier.
Réponses:
Pourquoi l'auteur précédent aurait-il signé les assemblées de cette manière?
Aucune idée, peut-être qu'il voulait que toutes ses assemblées soient signées avec la même clé.
La signature des assemblées est-elle nécessaire et qu'est-ce qui ne va pas à ne pas la signer?
Non, ce n'est pas nécessaire mais c'est un mécanisme vous permettant de garantir l'authenticité d'un assemblage. Cela vous permet de vous assurer qu'un assemblage n'a pas été falsifié et qu'il provient bien de cet auteur. Il est également nécessaire si vous souhaitez les mettre dans le GAC.
Quels inconvénients y a-t-il à signer des assemblées - cela entraîne-t-il des retards?
Les assemblys signés ne peuvent charger que d'autres assemblys signés. En outre, ils sont liés à une version spécifique, ce qui signifie que vous devez utiliser des redirections de liaison ou recompiler l'application si vous souhaitez utiliser une version différente. Il y a aussi un peu de surcharge de performance en raison de la vérification de la signature, mais c'est si peu que vous ne devriez pas vous inquiéter.
Vous devez signer des assemblys si vous souhaitez les placer dans le GAC .
Si vous signez un exécutable, toutes les bibliothèques de classes auxquelles il est lié doivent également être signées. Cela peut être difficile si vous utilisez une bibliothèque tierce (en particulier si vous devez utiliser un contrôle ActiveX ou similaire).
Richard Grimes a écrit un bon atelier sur la sécurité dans .NET et qui comprend un chapitre à ce sujet: Atelier de sécurité
La raison pour laquelle tous les assemblys sont signés avec le même fichier .snk pourrait être s'il utilisait des tests unitaires avec couverture de code. Pour pouvoir faire la couverture du code (au moins avec les outils intégrés dans la version de test de Visual Studio 2005) et si les assemblys sont signés, vous devez spécifier quels fichiers .snk sont utilisés pour la signature, mais je pense que vous ne pouvez spécifiez un fichier .snk pour l'ensemble de la solution, donc si vous signez les différentes bibliothèques de classes avec différents fichiers .snk, vous ne pouvez vérifier la couverture du code que sur l'un d'entre eux à la fois.
Une raison très importante de signer un assemblage est que vous puissiez être sûr qu'il s'agit de votre assemblage. Étant donné que la clé privée vous appartient, personne d'autre ne peut signer un assembly avec cette même clé. Cela signifie que lorsque la clé publique d'un assembly est celle que vous connaissez (vous pouvez la récupérer à l'aide de la GetType().Assembly.GetName().GetPublicKey()fonction), l'assembly vous appartient et n'a pas été falsifié.
Malgré toutes les utilisations de signature de dll, la dll ne doit être signée que pour deux raisons
1. Gestion des versions
2. Authentification
une. La gestion des versions indique la version sur laquelle la dll a été construite et tout en les poussant dans GAC, deux dll avec le même nom peuvent exister mais une version différente
b. L'authentification indique si la dll n'est pas falsifiée et existe de la même manière lorsqu'elle a été créée.
Si vous voulez en savoir plus sur les bases et la signature de dll, vous pouvez vous référer ici
En plus des réponses existantes, j'ajouterais que vous devez utiliser la signature lorsque votre DLL va être chargée et consommée dynamiquement par un logiciel tiers. Ce n'est pas une exigence technique en soi, mais il est rationnel, donc très courant, que le fabricant de logiciels tiers applique une telle politique en raison de préoccupations de sécurité.
Exemples où vous devez signer un assemblage: