Quelque chose ne va pas avec la non signature d'un assemblage .NET?

Question

Un de mes collègues est très attaché à la signature des assemblys. Littéralement, il tente de signer quoi que ce soit. Même lorsque nous utilisons des assemblages à partir de Microsoft qui ne sont pas signés, il va prendre le code source, de le signer et ensuite demander à d'autres développeurs d'utiliser sa copie à la place.

Je peux comprendre l'idée de base de la signature d'un montage: pour assurer un assemblage particulier n'est pas compromise par certaines douteux hacker. Donc, si nous sommes une société de développement de logiciels, nous devrions signer notre assemblée avant la libération de quelques .NET-library pour nos clients.

Cependant, nous avons principalement de développer des applications web pour notre propre usage ici, et je ne peux pas voir le point de la signature de chaque assemblée unique que nous utilisons.

Suis-je manqué quelque chose?

Answer 1

J'ai profité de la non-signé assemblées pour obtenir autour de questions avant et dans les milieux universitaires, montré aux gens pourquoi il est important. J'ai remplacé un fichier DLL qui est non signé (à nouveau dans un cadre académique) avec celui que j'ai fait avec le même nom, la même signature, et utilisés .NET Réflecteur de copier et de coller le code d'origine, mais dans la mienne, j'ai envoyé les noms d'utilisateur et mots de passe ont été transmis avant d'appeler le "réel" de code.

S'il est signé, vous pouvez faire une correspondance de signature, mais pas les remplacer. Contrairement à ce que l'Zippy dit, il y aura un moment de l'exécution de compliation erreur.

La signature des assemblées n'est jamais exagéré. Il faut 30 secondes. C'est comme de dire que le verrouillage des portes est exagéré si vous vivez dans le pays. Si vous voulez jouer avec vos affaires, aller de l'avant, de la laisser ouverte. Il suffit d'une violation de sécurité à me faire virer. Il ne faut que 30 secondes pour signer un assemblage et il y a aucune justification économique pas à. L'impact sur les performances est négligeable.

Answer 2

Signature d’assemblys qui est utilisés dans un sons environnement confiance exagéré pour moi.

Un point intéressant sur les assemblys signés, c’est qu’ils sont un peu plus lents à charger que des assemblys non signés, car elles doivent être vérifiées par chiffrement.

Pour signer un assembly, il dépend de tous les assemblys doivent également être signées. Ma conjecture est que cela contribue au désir de votre collègue à signer tout--le compilateur il est exigeant.

Answer 3

Un point supplémentaire: la signature de vos assemblées des pauses de compatibilité ascendante au fil des versions. Vos références commencent tous à inclure les numéros de version et les versions avec d'autres numéros de version sont considérés comme non-compatible. Ce qui entrave la mise à niveau vers des versions plus récentes de la participation aux assemblées.

À mon avis, vous ne devriez code-signature des assemblages si vous voyez certains de béton de gain:

• si vous déployez pour les environnements où non approuvé les gens sont susceptibles de toucher vos assemblées
• dans certains plug-in modèles, où vous voulez utiliser le certificat comme preuve de la mise à niveau de la confiance
• si votre code doit être appelée à partir d'autres ont signé le code (un projet comme, par exemple log4net, à juste titre les signes que leur code soit largement utilisable; ils l'ont foiré énormément de compatibilité par la perte de leur clé secrète il y a quelques années, un autre risque de signature de code).
• si vous souhaitez déployer le GAC

Answer 4

A votre collègue vous a donné aucune indication quant à pourquoi il aime à signer des assemblées? L'un des avantages de la signature qui n'a pas été discuté ici encore, c'est que seulement signé, les assemblées peuvent être mis dans le GAC (c'est à dire être partagées à l'échelle de la gestion des processus), mais les inconvénients ne semblent l'emporter sur les avantages de mon (sans doute inexpérimenté) point de vue.

Votre anecdote à propos de l'auto-signature de code Microsoft semble particulièrement suspect pour moi. Si MS n'a pas signé le code, il y a probablement une raison, non? Et en le signant, vous prenez la responsabilité si vous n'avez pas l'écrire - une autre occasion pour l'avenir de vous mordre.

Answer 5

Une autre chose sur la signature d’un assembly est, qu’on ne peut pas injecter celui incorrect à la place de vôtre (également - vous suite à un accident). Dans l’exemple, si vous créez un programme qui fait référence à un assembly Foo.dll, version 1.0, une personne peut créer l’ensemble, avec la même version et remplacer vôtre, lorsque vous vous connectez à votre bibliothèque, il ne sera pas possible (au moins je ne pense pas que c’est possible).