Ich habe eine Anwendung mit einer Vielzahl von Bibliotheken von Drittanbietern wie JSON.NET erstellt.Soll ich DLLs von Drittanbietern wie JSON.NET digital signieren?
Ich möchte sicherstellen, dass alle DLLs, aus denen meine Anwendung besteht, digital signiert sind, einschließlich der von Drittanbietern. Da diese nicht vom Autor signiert sind, kann/sollte ich die Drittanbieter einfach selbst unterschreiben?
Sprechen Sie über starke Benennung oder über Authenticode-Signaturen? Das Problem mit den letzteren ist, wenn die authenticode-signierte Assembly geladen wird, .NET validiert das Zertifikat und in einigen Konfigurationen (zB wenn OCSP überprüft werden muss und es nicht erreichbar ist), kann dies Dutzende von Sekunden dauern. Wir mussten damit aufhören, unsere Assemblys mit authenticode und X.509-Zertifikaten zu signieren. Ein weiterer Nachteil ist, dass, wenn die signierte Assembly von Malware in irgendeiner Weise verwendet wird, einige nicht kompetente Möchtegern-Spezialisten in Antiviren-Unternehmen (a) die Assembly als Malware markieren und (b) was schlimmer ist, beschweren an die Zertifizierungsstelle, die Ihr Codesignaturzertifikat ausgestellt hat, und das Zertifikat wird widerrufen.
.NET starke Benennung (mit einem Schlüsselpaar ohne Zertifikat) ist mehr oder weniger Ihr Privatgeschäft.
Update: Authenticode wird normalerweise auf Dateien im PE-Format (EXE und DLL), SYS und CAB angewendet. strong-naming ist reine .NET-Technik.
Die Warnmeldung spricht über Authenticode-Signatur. Das Signieren des Installers ist notwendig (das ist sicher) und reicht aus, um die Nachricht loszuwerden, es sei denn Systemrichtlinien sind so eingestellt, dass nur signierte Anwendungen ausgeführt werden können (in diesem Fall muss auch die EXE Ihrer Anwendung signiert werden).
Nur versucht (erfolglos) eine Antwort auf die gleiche Frage im Internet zu finden.
Was ich als Ergebnis getan habe, ist überprüft, wie Google und Adobe ihre Produkte liefern und festgestellt, dass jede Binärdatei in ihren Ordnern signiert ist, einschließlich der von Drittanbietern.
Einige Beispiele: 1. Google Chrome enthält pepflashplayer.dll, das urheberrechtlich von Adobe geschützt, aber digital von "Google Inc." signiert ist. 2. Adobe Reader enthält icudt40.dll, das von IBM urheberrechtlich geschützt ist, aber von "Adobe Systems" digital signiert wurde
Daher würde ich die beste Praxis annehmen, um alle Binärdateien zu signieren, die Ihre Anwendung bilden, einschließlich der dritten -party. Es macht Sinn, da es Ihnen hilft, Manipulationen zu vermeiden oder zumindest leicht zu erkennen, wenn dies auf dem Computer Ihres Kunden geschieht.
@EugeneMayevskiEldos: Danke. Ähm, ich bin mir nicht sicher - der Unterschied war mir nicht bewusst. Ich versuche nur, dass meine Anwendung installiert/ausgeführt wird, ohne dass die Warnung "Diese Anwendung ist nicht signiert" ausgelöst wird. –
Vielleicht sollte ich nur das Installationsprogramm und nicht die DLLs selbst unterschreiben? –
Ein Update hinzugefügt, um Ihre Fragen zu beantworten –