Quelque chose ne va pas en ne signant PAS un assembly .NET?

Un de mes collègues tient beaucoup à signer des assemblées. Il essaie littéralement de signer quoi que ce soit. Même lorsque nous utilisons des assemblys de Microsoft qui ne sont pas signés, il prendra le code source, le signera et demandera aux autres développeurs d'utiliser sa copie à la place.

Je peux comprendre l'idée de base derrière la signature d'un assemblage: s'assurer qu'un assemblage particulier n'est pas compromis par un pirate informatique douteux. Donc, si nous sommes une société de développement de logiciels, nous devons signer notre assemblage avant de publier une bibliothèque .NET pour nos clients.

Cependant, nous développons principalement des applications Web pour notre propre usage ici, et je ne vois tout simplement pas l'intérêt de signer chaque assemblage que nous utilisons.

Est-ce que j'ai râté quelque chose?

La signature d'assemblys utilisés dans un environnement de confiance me semble exagérée.

Un point intéressant sur les assemblys signés est qu'ils sont légèrement plus lents à charger que les assemblys non signés, car ils doivent être vérifiés par cryptographie.

Pour signer un assembly, tous les assemblys dont il dépend doivent également être signés. Je suppose que cela contribue au désir de votre collègue de tout signer - le compilateur l'exige.

EDIT Depuis la rédaction de cette réponse, vous pouvez voir que les camps pro et contre ont un support à peu près équivalent. Il n'y a clairement pas de bonne réponse ici.

Le point qui a motivé cette modification est que de nos jours, nous prenons tellement de bibliothèques open source de NuGet, et beaucoup d'entre elles ne sont pas signées du tout. Si vous souhaitez signer votre assembly, vous devez également signer toutes les dépendances. De nombreuses bibliothèques open source signées ont les clés privées utilisées pour la signature accessibles au public dans leurs référentiels source.

Comme pour tout, il y a des compromis à faire. D'après mon expérience de travail dans des environnements privés, les avantages de la signature sont principalement théoriques (ou académiques, comme le mentionne @ user289100 ), à moins que vous ne soyez préoccupé par le fait que les agences gouvernementales modifient votre code, auquel cas vous devez être paranoïaque sur tant de niveaux de votre infrastructure que la signature semblerait être un petit effort. Sinon, le nombre de défis qui découlent de l'obligation de tout signer ne semble pas en valoir la peine. Cependant, votre environnement peut avoir des exigences différentes, ou vous pouvez être masochiste!

Voir également la réponse de Teun D pour plus d'informations sur les défis liés aux assemblys de contrôle de version lors de l'utilisation de noms forts.

J'ai profité des assemblages non signés pour contourner les problèmes avant et dans les milieux universitaires, j'ai montré aux gens pourquoi c'est important. J'ai remplacé un fichier DLL qui n'était pas signé (encore une fois dans un cadre académique) par un fichier que j'avais créé avec le même nom, les mêmes signatures et utilisé .NET Reflector pour copier et coller le code d'origine, mais dans le mien, j'ai envoyé des noms d'utilisateur et des mots de passe qui étaient passés avant d'appeler du «vrai» code.

S'il est signé, vous pouvez faire correspondre la signature, mais pas la remplacer. Contrairement à ce que dit Zippy, il y aura une erreur de compliation d'exécution.

La signature d'assemblys n'est jamais excessive. Cela prend 30 secondes. C'est comme dire que verrouiller vos portes est exagéré si vous vivez à la campagne. Si vous voulez jouer avec vos affaires, allez-y, laissez-le ouvert. Il suffit d'une brèche de sécurité pour se faire virer. Cela ne prend que 30 secondes pour signer un assemblage et il n'y a aucune analyse de rentabilisation à ne pas faire. Les impacts sur les performances sont négligeables.

Un point supplémentaire: la signature de vos assemblys rompt la rétrocompatibilité des versions. Vos références commencent toutes à inclure des numéros de version et les versions avec d'autres numéros de version sont considérées comme non compatibles. Cela empêche la mise à niveau vers des versions plus récentes des assemblys distribués.

À mon avis, vous ne devriez signer les assemblys que si vous en voyez un gain concret:

• si vous déployez dans des environnements où des personnes non fiables pourraient toucher vos assemblages
• dans certains modèles de plug-ins, où vous souhaitez utiliser le certificat comme preuve pour la mise à niveau de la confiance
• si votre code doit être appelable à partir d'un autre code signé (un projet comme, disons log4net, signe à juste titre que son code soit largement utilisable; ils ont énormément gâché la compatibilité en perdant leur clé secrète il y a quelques années, un autre risque de signature de code) .
• si vous souhaitez déployer sur le GAC

Votre collègue vous a-t-il expliqué pourquoi il expliqué il aime signer des assemblées? Un avantage de la signature qui n'a pas encore été discuté ici est que seuls les assemblys signés peuvent être placés dans le GAC (c'est-à-dire être partagés entre les processus gérés), mais les inconvénients semblent l'emporter sur les avantages de ma perspective (certes inexpérimentée).

Votre anecdote sur le code Microsoft auto-signé me semble particulièrement suspecte. Si MS n'a pas signé le code, il y a probablement une raison, non? Et en le signant, vous en assumez la responsabilité quand vous ne l'avez pas écrit - une autre occasion pour l'avenir de vous mordre.

Une autre chose à propos de la signature d'un assemblage est qu'on ne peut pas en injecter un incorrect à la place du vôtre (aussi - vous-même par accident). Par exemple, si vous créez un programme qui fait référence à un assembly Foo.dll, version 1.0, quelqu'un peut créer un assembly, avec la même version, et remplacer le vôtre, lorsque vous signez votre bibliothèque, ce ne sera pas possible (à au moins je ne pense pas que ce soit facilement possible).

Les signatures ne sont nécessaires que si les assemblys sont placés dans le GAC, rien d'autre. Les assemblages signés n'empêchent pas quelqu'un de jouer avec eux. Un pirate informatique peut toujours retirer la signature et tout autre code qui vérifie la signature.

Je suis d'accord que cela semble un peu un gaspillage. Il est vraiment nécessaire de s'assurer que le fichier est ce que vous pensez être (et n'a pas été falsifié). Mais si vous faites confiance aux limites de la sécurité de votre réseau et de votre serveur Web, la signature de vos assemblys Web semble être une étape redondante.

Mais c'est peut-être mon expérience dans la petite entreprise qui parle. Si vous parlez d'un site Web de banque en ligne essentiel à votre mission, déconnectez-vous.

Pensez à le faire si vous allez expédier quelque chose et / ou avez réellement une raison de le faire. Dans tous les autres cas, c'est juste un tracas. Je demanderais à votre collègue ce qu'il retire réellement de faire cela.

J'ai déjà rencontré des assemblages signés et c'est une douleur postérieure, surtout si l'on considère le nombre de personnes qui ont peu ou pas de connaissances en matière de signature d'assemblages, à quoi cela sert et comment le faire. C'est juste une autre chose dont vous ne devriez pas avoir à vous soucier à moins que cela ne soit absolument nécessaire.

Vous devez signer votre assembly lorsqu'il est utilisé dans un ClickOnce XBAP déployé à partir du Web .

En outre, tous les assemblys référencés devront également être signés.

Nous signons nos assemblys car il y a des moments où nous obtenons des erreurs comme celle-ci (celle-ci provient de tests, mais peut se produire lors de l'exécution de l'application):

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)

Nous avons constaté que Visual Studio se trompe parfois et exécute un ancien code .

Si vous voulez une erreur si vous exécutez un ancien code, signez vos assemblys.

Si vous écrivez un package nuget , veuillez signer vos assemblys . Les assemblys non signés sont gênants pour nous qui voulons nous assurer que nous exécutons la dernière version de notre code. Je ne peux pas réparer Visual Studio . Tout ce que je peux faire, c'est détecter que Visual Studio s'est trompé. Alors s'il vous plaît, signez vos assemblages de pépites .