Ich habe ein C # /. NET 4.5 x64 Projekt in Visual Studio 2013. Mehr als ein Entwickler arbeitet an diesem Projekt, so dass der Code in Git verwaltet wird. Ich signiere die kompilierten .dll
s und .exe
mit signtool.exe
. Meine Firma hat ein Codesignaturzertifikat gekauft, und wenn ich es manuell über die Befehlszeile signiere:
... dann sieht alles gut aus: Ich bekomme eine Erfolgsmeldung und die Eigenschaften der kompilierten DLL im Windows Explorer zeigen es als korrekt signiert an. Also, ich habe kein Problem mit dem eigentlichen Signing-Prozess.
Aber das Zertifikat und sein Passwort dürfen nicht in Git enthalten sein . Sie werden allen Entwicklern des Projekts Out-of-Band zur Verfügung gestellt. Ich kann die Annahme machen, dass jeder Entwickler beim Erstellen des Projekts das Zertifikat an einem vordefinierten Ort auf seinem Computer gespeichert hat und er das Passwort dafür kennt.
Also, hier ist meine Frage: Wie kann ich Visual Studio 2013 so konfigurieren, dass es automatisch seine kompilierte Ausgabe signiert, ohne das Zertifikat oder sein Passwort in Git zu behalten? Ich möchte, dass es so einfach ist Entwickler hat das Zertifikat in einem vordefinierten Pfad (oder importiert, oder was auch immer), und unter der Annahme, dass der Entwickler das Kennwort für das Zertifikat kennt, dass das Klicken auf "Erstellen" in Visual Studio 2013 nur erstellt und signiert, keine Fragen gestellt.
Wenn der Signiervorgang nicht interaktiv sein kann (keine Passwortabfrage), ist das ein Bonus. Schließlich wird dies Teil eines Continuous Integration (CI) -Servers sein, der auch seine Ausgabe signieren kann, und weil es automatisiert ist, wird niemand da sein, um das Passwort einzugeben. Allerdings werde ich keine Lösung für jetzt nehmen.
Mein Zertifikat ist ein PKCS # 12-Format und ist mit einem Passwort geschützt. Windows behauptet, dass es nicht für den Export markiert ist.
Eine Lösung, die ich zuvor verwendet habe, ähnelt der Antwort von @ Mikko, aber sie ist in zwei Teile aufgeteilt:
Ein lokales nicht gesteuertes Skript, das nur eine Umgebungsvariable mit dem Kennwort festlegt. Dies ist die Datei, die Sie jedem Entwickler geben.
%Vor%Ein quellengesteuertes Skript, das das vorherige Skript aufruft und das eigentliche Signieren.
%Vor% Das Paar setlocal
/ endlocal
stellt sicher, dass das Kennwort nicht in die Umgebung gelangt, wenn das Skript manuell ausgeführt wird.
Der "%1"
ist der Pfad zur ausführbaren Datei, der als Skriptparameter im Post-Build-Schritt übergeben wird.
..
Eine andere Möglichkeit besteht darin, das Zertifikat in den privaten Zertifikatsspeicher des Entwicklers zu importieren und dann den Fingerabdruck mit dem Signal-Tool wie folgt zu verwenden:
%Vor%Dann brauchen Sie nur das Passwort beim ersten Import des Zertifikats und nicht während der Builds.
Sie könnten eine Datei batch
in Ihrem Projektverzeichnis hinzufügen, zum Beispiel sign.bat
.
Fügen Sie die Datei zu Ihrem .gitignore
hinzu, fügen Sie sie jedoch nicht dem Visual Studio-Projekt hinzu.
Rufen Sie in den Eigenschaften Ihres Projekts batch
als Post-Build-Ereignis auf.
Das Aufrufen von signtool von VS2015 funktionierte für mich nicht, wenn ich das Passwort in der Form "$ (SIGNPASS)" eingegeben habe, aber es funktionierte, wenn Sie die Notation "% SIGNPASS%" verwenden.
Wenn Sie überprüfen, wie der vollständige Befehl signtool im VS-Ausgabefenster gebildet wurde, sehen die Befehle gleich aus, aber unter der Haube gibt es einen Unterschied.
Denken Sie daran, doppelte Pfade anzugeben, um sich vor Pfaden zu schützen, die Leerzeichen enthalten:)
Als neuere Alternative zu diesen Produkten habe ich einen Code Signing Service entwickelt, den Einzelpersonen und Organisationen in ihren Azure-Umgebungen einsetzen können, um Code-Signaturen zu automatisieren und gleichzeitig sicherzustellen, dass die privaten Schlüssel das HSM von Key Vault nicht verlassen.
Details finden Sie auf der Projektseite hier: Ссылка
Tags und Links c# visual-studio-2013 code-signing signtool