Kann in SQL Server 2014 ein asymmetrischer Schlüssel für eine .NET Framework-Assembly erstellt werden?

Nein, ich habe noch nie einen Weg gefunden dies zu erreichen. Der Schlüssel, der zum Signieren der .NET Framework-Assembly verwendet wird, ist intern / privat für Microsoft. Die Optionen versuchten:

• Privater Schlüssel extrahieren / in SQL Server laden: nicht möglich, sonst wäre der Schlüssel nicht "privat". Das Signatur- / starke Benennungssystem ist effektiv, da Außenstehende nicht behaupten können, dass sie den Code signiert haben.

• Eine Signatur hinzufügen: Ich habe versucht, eine neue mit dem Dienstprogramm sn hinzuzufügen. Funktioniert nicht aufgrund von:

    

  Die Assembly konnte nicht erneut signiert werden - Der öffentliche Schlüssel der Assembly stimmte nicht mit dem öffentlichen Signierungsschlüssel überein.

  Aber selbst wenn dies funktioniert, bedeutet das möglicherweise nicht, dass das Laden in SQL Server funktioniert, da es nicht dieselbe Assembly ist, die Sie Ihrem Projekt als Ressource hinzugefügt haben. Andere .NET Framework-DLLs kennen bei anderen Abhängigkeiten nur die ursprüngliche Signatur.

• Entfernen Sie die aktuelle Signatur und fügen Sie eine neue hinzu: Ich habe versucht, ILDASM zu verwenden, um System.Runtime.Serialization.dll zu disassemblieren, und dann einen neuen privaten Schlüssel aus sn -k hinzuzufügen und dann erneut mit ILASM zu verknüpfen. co_de% step (und ich habe keine Zeit, weiter zu untersuchen).

  Aber genau wie bei der obigen Option müssten Sie, selbst wenn das funktioniert, den Json.NET-Projektreferenz für ILASM auf diese neue DLL ändern, sie neu kompilieren und dann Ihre Projektreferenz als neue DLL ändern und kompiliere das dann neu. Aber das würde Ihnen nur die Möglichkeit geben, die DLLs sauber zu laden, es würde nicht garantieren, dass sie funktionieren würden, wenn sie externe Abhängigkeiten haben, die die ursprüngliche Microsoft-Signatur erwarten.

Im Wesentlichen, wenn Sie DLLs laden, die Sie nicht in Bezug auf die Signatur kontrollieren, dann besteht die einzige Hoffnung darin, mit System.Runtime.Serialization zu dekompilieren und mit ILDASM neu zu kompilieren, indem Sie eine neue ILASM Datei angeben, aber das wird nicht funktionieren, wenn andere Assemblys mit denen verbunden sind, die neu kompiliert werden. Und sicherlich fallen .NET Framework DLLs in diese Kategorie.

Einfach ausgedrückt: Wenn Sie nicht unterstützte .NET Framework-DLLs laden, müssen Sie snk festlegen.

ABER : Denken Sie daran, dass selbst wenn dies funktioniert, um alles über einen asymmetrischen Schlüssel oder ein Zertifikat zu laden, dies nicht bedeutet, dass Sie keine funktionalen Probleme haben. Es gibt einen Grund, warum diese Bibliotheken nicht genehmigt / validiert wurden. Es gibt Code in ihnen Dinge zu tun, die auf eine Weise funktionieren könnten, die Sie nicht erwarten, wie das Speichern von Daten in statischen Feldern. In Windows- und Konsolen-Apps ist dies kein Problem, da es eine Anwendung pro App-Domain ist. SQLCLR verwendet jedoch eine freigegebene Anwendungsdomäne, sodass mehrere SQL Server-Sitzungen diese statischen Variablen gemeinsam nutzen. Es kann sein, dass die von der Json.NET-Bibliothek aufgerufenen Methoden diese unsicheren Dinge nicht verwenden, aber es gibt keine Möglichkeit zu wissen, und selbst wenn wir es wüssten, können wir nicht viel dagegen tun: - (.

Eine Sache, über die ich nachgedacht habe, ist das Durchlaufen der in der nicht unterstützten .NET Framework-DLL aufgerufenen Methoden und die Annahme, dass nichts Unsicheres geschieht, indem dieser Code direkt in das Projekt kopiert wird. Theoretisch sollte das funktionieren, solange die Aufrufe in TRUSTWORTHY ON keine anderen nicht unterstützten DLLs aufrufen oder "unsichere" Dinge machen usw. Aber ich hatte keine Zeit, das auszuprobieren.

Ich habe dies unter SQL Server 2014 (Version 11.0.6248.0) für das .Net Framework 4 System.Drawing.dll unter Verwendung des folgenden Skripts

SQL Server akzeptiert diese Assembly, gibt jedoch eine Warnung ab:

  

Warnung: Die Microsoft .NET Framework-Assembly 'system.drawing,   Version = 4.0.0.0, Kultur = neutral, publickeytoken = b03f5f7f11d50a3a,   processorarchitecture = msil. ' Sie registrieren sich nicht vollständig getestet   in der gehosteten SQL Server-Umgebung und wird nicht unterstützt. In dem   Wenn Sie diese Assembly oder das .NET Framework aktualisieren oder   Ihre CLR-Integrationsroutine funktioniert möglicherweise nicht mehr. Bitte beziehen Sie sich auf SQL Server   Onlinedokumentation für weitere Details.

Um sicherzustellen, dass die thustworthy Einstellung deaktiviert ist, lief ich die folgende Abfrage von Eine Warnung über die Datenbankoption TRUSTWORTHY :

Was ergab keine Ergebnisse. Natürlich habe ich jetzt WITH PERMISSION_SET = UNSAFE , aber das scheint weniger problematisch.

System.Drawning.dll ist eine Abhängigkeit, die ich für eine Drittanbieter-Assembly benötige. Ich bin mir ziemlich sicher, dass die Methoden, die ich anrufe, nichts in System.Drawing aufrufen, also behalte ich die Dinge vorerst so.

Außerdem wurde beim Erstellen meiner eigenen benutzerdefinierten Assembly ein Fehler angezeigt. Ich habe den genauen Fehler verloren, aber erwähnt Synchonization und es referenzierte System.Diagnostics, was mir half, einen Aufruf von Debug.WriteLine zu finden. Nach der Removierung konnte die Assembly erstellt werden und alles war in Ordnung.