Unterzeichnen Sie jede ausführbare Datei mit einem Authenticode-Zertifikat über MSBuild

8

Ich habe ein Authenticode Zertifikat (.pfx), mit dem ich ausführbare Dateien signieren kann.

Wie kann ich Team Build so konfigurieren, dass jede einzelne ausführbare Datei signiert wird (.exe, .dll,. ..) automatisch beim Erstellen des Projekts?

    
Mephisztoe 28.08.2009, 13:44
quelle

4 Antworten

15

Hier ist die Methode, die wir verwenden:

  1. Entladen Sie das WiX-Projekt und wählen Sie Bearbeiten

  2. Scrolle nach unten, wo du <Import Project="$(WixTargetsPath)" />

  3. findest
  4. Fügen Sie unmittelbar darüber eine neue Zeile hinzu: <Import Project="ProjectName.custom.targets" /> Wir verwenden die Namenskonvention "ProjectName.custom.targets", aber die Datei kann beliebig benannt werden.

  5. Erstellen Sie eine neue XML-Datei namens ProjectName.custom.Targets und fügen Sie den folgenden Code ein:

    %Vor%

Erstellen Sie ein Test-Authenticode-Zertifikat (wir haben unser AuthenticodeTest.pfx genannt) und platzieren Sie es in der Quellcodeverwaltung - der Pfad dazu wird in der AuthenticodeCertFile-Eigenschaft festgelegt. Um es auszuprobieren, führen Sie msbuild an der Befehlszeile aus und ändern Sie die OutDir-Eigenschaft - dh / msbuild Test.sln / p: OutDir = C: \ Test

Einige Anpassungen werden benötigt, wenn:

  • Wenn Sie die Elementgruppe "privat" (ich habe betrogen) nicht verwenden möchten
  • Wenn Sie keine WiX-Projektreferenzen verwenden
  • Wenn Ihre cab-Dateien vom MSI getrennt sind, müssen sie ebenfalls signiert werden

Um den endgültigen Build auszuführen, wählen Sie "Neue Warteschlange erstellen" in TFS. Klicken Sie auf "Parameter" und erweitern Sie "Erweitert". Unter "MSBuild Arguments" fügen Sie /p:AuthenticodeCertFile=ProductionCertFile.pfx /p:AuthenticodePassword=Secret hinzu. Beachten Sie, dass dies möglicherweise nicht vollständig sicher ist - es könnte schwierig sein, dass der Erstellungsagent die PFX-Datei findet, ohne sie einzuchecken, und das Kennwort könnte in der Build-Ausgabe protokolliert werden. Alternativ könnten Sie einen speziellen gesperrten Build-Agenten dafür erstellen oder den Build lokal in der Befehlszeile ausführen - aber das wäre natürlich keine "Reinraum" -Umgebung. Es kann sich lohnen, speziell für diesen Zweck einen speziellen gesperrten "sauberen" Server zu erstellen.

    
ShadowChaser 07.06.2011 15:26
quelle
3

Ich stimme nicht zu. Da das Code Signing-Zertifikat auf dem Build-Computer installiert werden muss, um das Signieren durchzuführen, sollten Sie nicht jedes Mal signieren, was auf diesem Computer erstellt wird. Der Computer ist "gefährdet", da das Code-Signaturzertifikat installiert ist, so dass es in gewisser Weise geschützt werden muss (physische Sicherheit und Systemsicherheit). Wenn es geschützt ist, warum sollte es nicht die Arbeit machen, die es beabsichtigt hat, die Dateien für die Lieferung vorbereiten, konsistent, wiederholbar, jedes Mal?

Leider scheint die Antwort "nicht" auch die Standard-Antwort von Microsoft zu sein, da sie in MSBuild fast keine Unterstützung bietet, um eine Liste von Dateinamen zu durchlaufen, indem sie für jeden Dateinamen einmal ein Programm aufruft Liste. Ich habe Wege gefunden, um eine Wildcard-generierte Liste von Dateien an das Programm Signntool.exe übergeben, aber es kann immer nur eine Datei zu einem Zeitpunkt.

Ich fürchte (für mich), dass es wieder eine Batch-Datei zu schreiben gibt, die ihre Argumente durchläuft und für jedes Argument signtool aufruft. Das Schreiben von Batch-Dateien für die übliche Aufgabe, eine Build-Ausgabe zu signieren, lässt mich denken, dass MSBuild wirklich nicht so ausgereift ist wie ein Build-System. Entweder das oder signtool hat die falsche Schnittstelle. In beiden Fällen scheint das Signieren mehrerer Dateien ohne Aufzählung des Namens jeder zu signierenden Datei mit MSBuild ein "No Go" zu sein.

    
Mark Waite 29.10.2009 23:55
quelle
2

Meine Antwort baut auf der Antwort von ShadowChaser auf. Der Unterschied, dass mein MSBuild-Ziel eine angegebene Datei signiert oder wenn keine angegeben wird, wird die Build-Ausgabe des Projekts signieren, von dem das Ziel aufgerufen wurde.

Speichern Sie Folgendes in einer Zieldatei, sagen wir signing.custom.targets. Sobald Sie es gespeichert haben, fügen Sie es einfach in Ihr csproj oder wixproj ein und verwenden Sie das Ziel, um Ihre Ausgabe zu signieren. Dies funktioniert auch auf der lokalen Dev-Maschine als sign.properties (es ist ein Hybrid-Dev-Env, so dass wir die Eigenschaften von cert nicht zweimal angeben wollten). Die Datei existiert nicht auf der lokalen Dev-Box.

um eine Datei über die Befehlszeile zu signieren, können Sie dies tun

%Vor%

signing.custom.targets-Definition

%Vor%

einschließlich es in Ihrem csproj

%Vor%

um es in deinen wixproj aufzunehmen

%Vor%     
Dhawalk 20.11.2015 16:50
quelle
-4

Nicht.

Sie möchten Builds nicht automatisch signieren. Die meisten Builds müssen sowieso nicht signiert werden. Sie werden nur für die Automatisierung von Tests verwendet. Einige Builds können an Ihre internen Tester weitergegeben werden. Aber nur Builds, die Sie tatsächlich außerhalb Ihrer Organisation veröffentlichen, benötigen Authenticode-Signaturen.

In diesem Fall sollten Sie nach der Unterzeichnung trotzdem einen manuellen Überprüfungsschritt durchführen. Bei der manuellen Signierung wird also kein zusätzlicher manueller Schritt in den Freigabevorgang eingefügt, und die Automatisierung spart sehr wenig Zeit. Im Gegenzug wird es viel weniger signierte Dateien in Ihrer Organisation geben, und Sie können viel stärkere Garantien für die Dateien geben, die das sind.

    
MSalters 28.08.2009 14:57
quelle