Stimmt etwas nicht, wenn Sie keine .NET-Assembly signieren?

Einer meiner Kollegen ist sehr daran interessiert, Versammlungen zu unterzeichnen. Er versucht buchstäblich alles zu unterschreiben. Selbst wenn wir Assemblys von Microsoft verwenden, die nicht signiert sind, nimmt er den Quellcode, signiert ihn und bittet andere Entwickler, stattdessen seine Kopie zu verwenden.

Ich kann die Grundidee hinter dem Signieren einer Assembly verstehen: um sicherzustellen, dass eine bestimmte Assembly nicht von einem zwielichtigen Hacker kompromittiert wird. Wenn wir also ein Softwareentwicklungsunternehmen sind, sollten wir unsere Assembly signieren, bevor wir eine .NET-Bibliothek für unsere Kunden freigeben.

Wir entwickeln hier jedoch hauptsächlich Webanwendungen für den eigenen Gebrauch, und ich kann mir nicht vorstellen, jede einzelne Baugruppe, die wir verwenden, zu signieren.

Vermisse ich hier etwas?

Das Signieren von Assemblys, die in einer vertrauenswürdigen Umgebung verwendet werden, klingt für mich nach einem Overkill.

Ein interessanter Punkt bei signierten Assemblys ist, dass sie etwas langsamer geladen werden als nicht signierte Assemblys, da sie kryptografisch überprüft werden müssen.

Um eine Baugruppe zu signieren, müssen auch alle Baugruppen signiert werden, von denen sie abhängt. Ich vermute, dass dies zum Wunsch Ihres Kollegen beiträgt, alles zu signieren - der Compiler fordert es.

BEARBEITEN Seit Sie diese Antwort geschrieben haben, können Sie sehen, dass sowohl der Profi als auch der Gegner ungefähr die gleiche Unterstützung haben. Hier gibt es eindeutig keine richtige Antwort.

Der Punkt, der diese Bearbeitung erzwungen hat, ist, dass wir heutzutage so viele Open-Source-Bibliotheken von NuGet nehmen und viele von ihnen überhaupt nicht signiert sind. Wenn Sie Ihre Assembly signieren möchten, müssen auch Abhängigkeiten signiert sein. Viele der signierten Open Source-Bibliotheken verfügen über die privaten Schlüssel zum Signieren, die öffentlich verfügbar sind, und sind in ihren Quellrepositorys verfügbar.

Wie bei allem müssen Kompromisse geschlossen werden. Nach meiner Erfahrung in der Arbeit in privaten Umgebungen sind die Vorteile des Signierens meist theoretisch (oder akademisch, wie @ user289100 erwähnt), es sei denn, Sie befürchten, dass Regierungsbehörden Ihren Code ändern. In diesem Fall müssen Sie in Bezug auf so viele Ebenen paranoid sein Ihre Infrastruktur, die das Signieren scheint, scheint ein kleiner Aufwand zu sein. Ansonsten scheint sich die Menge an Herausforderungen, die sich daraus ergeben, dass man nicht alles unterschreiben muss, einfach nicht zu lohnen. Ihre Umgebung kann jedoch andere Anforderungen haben, oder Sie können ein Masochist sein!

Siehe auch die Antwort von Teun D für Informationen zu Herausforderungen im Zusammenhang mit der Versionierung von Assemblys bei Verwendung starker Namen.

Ich habe nicht signierte Versammlungen genutzt, um Probleme zu umgehen, und in akademischen Umgebungen den Leuten gezeigt, warum es wichtig ist. Ich habe eine DLL-Datei, die nicht signiert war (wieder in einer akademischen Umgebung), durch eine ersetzt, die ich mit demselben Namen und denselben Signaturen erstellt habe, und mit .NET Reflector den Originalcode kopiert und eingefügt, aber in meiner habe ich Benutzernamen und Kennwörter per E-Mail gesendet wurden übergeben, bevor "echter" Code aufgerufen wurde.

Wenn signiert, können Sie eine Signaturübereinstimmung vornehmen, diese jedoch nicht ersetzen. Im Gegensatz zu Zippy tritt zur Laufzeit ein Kompatibilitätsfehler auf.

Das Signieren von Baugruppen ist niemals übertrieben. Es dauert 30 Sekunden. Es ist, als würde man sagen, dass es übertrieben ist, die Türen zu verschließen, wenn man auf dem Land lebt. Wenn Sie mit Ihren Sachen spielen möchten, lassen Sie es offen. Es dauert nur eine Sicherheitsverletzung, um gefeuert zu werden. Das Signieren einer Baugruppe dauert nur 30 Sekunden, und es gibt keinen Geschäftsfall, dies nicht zu tun. Die Auswirkungen auf die Leistung sind vernachlässigbar.

Ein weiterer Punkt: Durch das Signieren Ihrer Assemblys wird die Abwärtskompatibilität gegenüber Versionen beeinträchtigt. Ihre Referenzen enthalten alle Versionsnummern und Versionen mit anderen Versionsnummern gelten als nicht kompatibel. Dies behindert das Upgrade auf neuere Versionen verteilter Assemblys.

Meiner Meinung nach sollten Sie Baugruppen mit Codezeichen nur dann verwenden, wenn Sie einen konkreten Vorteil daraus ziehen:

• Wenn Sie in Umgebungen bereitstellen, in denen nicht vertrauenswürdige Personen Ihre Assemblys möglicherweise berühren
• In bestimmten Plug-In-Modellen, in denen Sie das Zertifikat als Nachweis für die Aktualisierung der Vertrauensstellung verwenden möchten
• Wenn Ihr Code von einem anderen signierten Code aus aufgerufen werden kann (ein Projekt wie beispielsweise log4net signiert seinen Code zu Recht als weit verbreitet); die Kompatibilität wurde durch den Verlust ihres geheimen Schlüssels vor einigen Jahren erheblich beeinträchtigt, ein weiteres Risiko der Codesignatur.) .
• Wenn Sie im GAC bereitstellen möchten

Hat Ihr Kollege Ihnen Hinweise gegeben, warum er gerne Versammlungen unterzeichnet? Ein Vorteil beim Signieren, der hier noch nicht erörtert wurde, besteht darin, dass nur signierte Assemblys in den GAC gestellt werden können (dh von verwalteten Prozessen gemeinsam genutzt werden), aber die Nachteile scheinen aus meiner (zugegebenermaßen unerfahrenen) Perspektive die Vorteile zu überwiegen.

Ihre Anekdote über die Selbstsignierung von Microsoft-Code scheint mir besonders verdächtig. Wenn MS den Code nicht signiert hat, gibt es wahrscheinlich einen Grund, oder? Und wenn Sie es unterschreiben, übernehmen Sie die Verantwortung dafür, wenn Sie es nicht geschrieben haben - eine weitere Gelegenheit für die Zukunft, Sie zu beißen.

Eine andere Sache beim Unterzeichnen einer Versammlung ist, dass man keine falsche anstelle Ihrer verspritzen kann (auch - Sie selbst durch einen Unfall). Wenn Sie beispielsweise ein Programm erstellen, das auf eine Assembly Foo.dll, Version 1.0, verweist, kann jemand eine Assembly mit derselben Version erstellen und Ihre ersetzen, wenn Sie Ihre Bibliothek signieren. Dies ist nicht möglich (at Zumindest glaube ich nicht, dass es leicht möglich ist.

Signaturen sind nur erforderlich, wenn die Baugruppen im GAC platziert sind, sonst nichts. Signierte Baugruppen hindern niemanden daran, sich mit ihnen anzulegen. Ein Hacker kann weiterhin die Signatur und jeden anderen Code entfernen, der nach der Signatur sucht.

Ich stimme zu, es scheint eine Verschwendung zu sein. Es ist wirklich notwendig, um sicherzustellen, dass die Datei so ist, wie Sie denken (und nicht manipuliert wurde). Wenn Sie jedoch den Grenzen Ihrer eigenen Netzwerksicherheit und Ihres Webservers vertrauen, erscheint das Signieren Ihrer Webassemblys als redundanter Schritt.

Aber vielleicht ist das meine Erfahrung als Kleinunternehmer. Wenn Sie über eine geschäftskritische Online-Banking-Website sprechen, melden Sie sich ab.

Denken Sie darüber nach, wenn Sie etwas versenden und / oder tatsächlich einen Grund dafür haben. In jedem anderen Fall ist es nur Ärger. Ich würde Ihren Arbeitskollegen fragen, was er davon hat.

Ich bin schon einmal auf signierte Assembly-Itis gestoßen, und es ist ein Schmerz im hinteren Bereich, besonders wenn man bedenkt, wie viele Leute wenig bis gar nichts über das Signieren von Assemblys wissen, wofür es ist und wie es zu tun ist. Es ist nur eine andere Sache, mit der Sie sich nicht befassen sollten, es sei denn, dies ist absolut notwendig.

Sie müssen Ihre Assembly signieren, wenn sie in einem ClickOnce XBAP aus dem Web bereitgestellt wird .

Darüber hinaus müssen auch alle Assemblys, auf die verwiesen wird, signiert werden.

Wir signieren unsere Assemblys, weil manchmal Fehler wie die folgenden auftreten (diese stammen aus Tests, können jedoch beim Ausführen der Anwendung auftreten):

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)

Wir hatten festgestellt, dass Visual Studio manchmal etwas falsch macht und alten Code ausführt .

Wenn Sie einen Fehler wünschen, wenn Sie alten Code ausführen, signieren Sie Ihre Assemblys.

Wenn Sie ein Nuget- Paket schreiben , unterschreiben Sie bitte Ihre Baugruppen . Nicht signierte Assemblys sind für uns umständlich, wenn wir sicherstellen möchten, dass wir die neueste Version unseres Codes ausführen. Ich kann Visual Studio nicht reparieren . Ich kann nur feststellen, dass Visual Studio etwas falsch gemacht hat. Bitte unterschreiben Sie Ihre Nuget-Baugruppen .