en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Cloud Code Signing-Integration mit GitLab CI

Dies ist ein Tutorial, wie man mit eSigner CodeSignTool automatisierte Codesignaturen auf GitLab CI durchführt. 

CodeSignTool ist ein sicheres Befehlszeilenprogramm, das Teil von eSigner ist: unserer Cloud-Code-Signaturumgebung, die Softwareherausgebern und -entwicklern zugute kommt, da sie in der Lage ist, Codesignaturen für Unternehmen sicher und effizient auf unkomplizierte Weise durchzuführen.  Der Beispiel-Workflow unten zeigt einen .NET-DLL-Code, der auf GitLab CI mit eSigner signiert wird.

SSL.com EV Codesignatur Zertifikate helfen, Ihren Code vor unbefugter Manipulation und Kompromittierung mit dem höchsten Validierungsniveau zu schützen, und sind für so wenig wie erhältlich $ 249 pro Jahr. Sie können auch Verwenden Sie Ihr EV Code Signing-Zertifikat in großem Maßstab in der Cloud mit eSigner.

BESTELLEN SIE JETZT!

Umgebungsvariablen

  • USERNAME: Benutzername des SSL.com-Kontos. (Erforderlich)
  • PASSWORD: Kennwort für das SSL.com-Konto (erforderlich)
  • CREDENTIAL_ID: Anmelde-ID zum Signieren des Zertifikats. Wenn credential_id ausgelassen wird und der Benutzer nur ein eSigner-Codesignaturzertifikat hat, verwendet CodeSignTool standardmäßig dieses. Wenn der Benutzer über mehr als ein Codesignaturzertifikat verfügt, ist dieser Parameter obligatorisch. (Erforderlich)
  • TOTP_SECRET: OAuth-TOTP-Geheimnis. Detaillierte Informationen erhalten Sie unter https://www.ssl.com/how-to/automate-esigner-ev-code-signing (Pflichtfeld)
  • ENVIRONMENT_NAME : 'TEST'- oder 'PROD'-Umgebung. (Erforderlich)

Eingänge

  • input_file_path: Pfad des zu signierenden Codeobjekts. (Erforderlich)
  • output_dir_path: Verzeichnis, in das signierte Codeobjekte geschrieben werden. Wenn output_path weggelassen wird, wird die in -file_path angegebene Datei mit der signierten Datei überschrieben.

.NET-Code-DLL-Signierungsbeispiel-Workflow

Erstellen Sie eine yml-Datei

Gruppieren Sie Jobs in Phasen. Alle Jobs in einer Stufe müssen abgeschlossen sein, bevor die nächste Stufe ausgeführt wird.

Etappen: - Bauen - Signieren
 

Umgebungsvariablen global definieren. Die Eigenschaft auf Jobebene überschreibt globale Variablen.

  • Umgebungsvariablen werden verwendet, um die Beispiele besser lesbar zu machen. Im obigen Screenshot des Beispielworkflows wurden PROJECT_NAME, PROJECT_VERSION und DOTNET_VERSION optional weggelassen. Die Unterzeichnung kann auch mit diesen Auslassungen fortgesetzt werden.  
  • Geben Sie unter ENVIRONMENT_NAME „TEST“ für Testsignaturen und „PROD“ für Livesignaturen ein.
Variablen: PROJECT_NAME: „HelloWorld“ PROJECT_VERSION: „0.0.1“ DOTNET_VERSION: „3.1“ ENVIRONMENT_NAME: „PROD“
 

Definiere das Stufe bauen

Nachfolgend finden Sie die Definition Ihres Jobs zum Erstellen von DLL-Artefakten

build-dotnet:

 

  1. Definieren Sie, in welcher Phase der Job ausgeführt wird.
  Stufe: bauen

 

  1. Geben Sie den vollständigen Namen des Bildes ein, das verwendet werden soll. Es sollte den Registrierungsteil enthalten, falls erforderlich.
 Bild: mcr.microsoft.com/dotnet/sdk:3.1-bullseye

 

  1. Definieren Sie Skripte, die *vor* dem Job ausgeführt werden sollen. Kann global oder pro Job eingestellt werden.
before_script: - mkdir -p ${CI_PROJECT_DIR}/artifacts - mkdir -p ${CI_PROJECT_DIR}/packages

 

  1. Definieren Sie Shell-Skripte, die vom Runner ausgeführt werden. DLL-Artefakt erstellen
Skript: - dotnet build dotnet/${PROJECT_NAME}.csproj -c Release - cp dotnet/bin/Release/netcoreapp${DOTNET_VERSION}/${PROJECT_NAME}-${PROJECT_VERSION}.dll ${CI_PROJECT_DIR}/packages/${ PROJECT_NAME}.dll

 

  1. Geben Sie eine Liste von Dateien und Verzeichnissen an, die an den Job angehängt werden sollen, wenn er erfolgreich ist.
  • Dieabgelaufen_in'-Eigenschaft ermöglicht das Löschen der Datei nach einer bestimmten Zeit. Seine Verwendung ist optional. Aus diesem Grund zeigt der Screenshot des obigen Beispiel-Workflows diese Eigenschaft nicht.
Artefakte: Pfade: - ${CI_PROJECT_DIR}/packages/HelloWorld.dll expire_in: 5 Minuten
 

Definieren Sie die Zeichenphase

Nachfolgend finden Sie die Definition Ihres Jobs zum Signieren von DLL-Artefakten

Sign-Dotnet-Artefakte:

 

  1. Definieren Sie, in welcher Phase der Job ausgeführt wird.
  Stufe: Zeichen

 

  1. Geben Sie den vollständigen Namen des Bildes ein, das verwendet werden soll. Es sollte den Registrierungsteil enthalten, falls erforderlich.
 Bild: docker:19.03.0

 

  1. Dienste definieren. Dies ähnelt der Eigenschaft „image“, verknüpft jedoch die angegebenen Dienste mit dem Container „image“.
dienste: - docker:19.03.0-dind

 

  1. Definieren Sie Umgebungsvariablen für bestimmte Jobs.
  • Im obigen Screenshot wurde der Sign-Befehl direkt im Sign-Skript und nicht unter Umgebungsvariablen definiert. BBeide Methoden können mit TravisCI korrekt signieren.
  Variablen: BEFEHL: "Zeichen"

 

  1. Definieren Sie Skripte, die *vor* dem Job ausgeführt werden sollen. Kann global oder pro Job eingestellt werden.
  before_script: - mkdir -p ${CI_PROJECT_DIR}/artifacts - mkdir -p ${CI_PROJECT_DIR}/packages

 

  1. Platzieren Sie Shell-Skripte, die vom Runner ausgeführt werden. Signieren Sie das .NET-DLL-Artefakt mit dem CodeSignTool Docker Image
script: - docker pull ghcr.io/sslcom/codesigner:latest - docker run -i --rm --dns 8.8.8.8 --network host --volume ${CI_PROJECT_DIR}/packages:/codesign/examples --volume $ {CI_PROJECT_DIR}/artifacts:/codesign/output -e USERNAME=${USERNAME} -e PASSWORD=${PASSWORD} -e CREDENTIAL_ID=${CREDENTIAL_ID} -e TOTP_SECRET=${TOTP_SECRET} -e ENVIRONMENT_NAME=${ENVIRONMENT_NAME} ghcr.io/sslcom/codesigner:latest ${COMMAND} -input_file_path=/codesign/examples/${PROJECT_NAME}.dll -output_dir_path=/codesign/output

 

  1. Schreiben Sie das Skript, das verwendet werden kann, um eine Liste von Dateien und Verzeichnissen anzugeben, die an den Job angehängt werden sollen, wenn er erfolgreich ist.
Artefakte: Pfade: - ${CI_PROJECT_DIR}/artifacts/${PROJECT_NAME}.dll Verfallsdatum: 1 Tage

 

  1. Geben Sie eine Liste mit Jobnamen aus früheren Stadien an, aus denen Artefakte geladen werden sollen.
Abhängigkeiten: - build-dotnet
 

Initiieren Sie die Build-Phase

Erstellen Sie ein Repository

Beachten Sie die Befehlszeilenanweisungen auf Gitlab, wie im folgenden Screenshot zu sehen

Drücken Sie Ihren Ordner

Tun Sie dies durch Anklicken Terminal auf der Speisekarte, gefolgt von Neues Terminal.

Geben Sie das Push-Skript auf Ihrem Terminal ein, um das Projekt zu pushen 

Klicken Sie auf die Schaltfläche Erstellen

Fahren Sie nach dem Auslösen der Pipeline mit dem Erstellen fort

Überprüfen Sie, ob der Build erfolgreich ist  

Leiten Sie die Zeichenphase ein

Fahren Sie fort, um das Artefakt zu signieren

Bestätigen Sie, ob die Codesignatur erfolgreich war

Sie können die signierte Datei jetzt herunterladen

Sie können auf die verweisen SSL.com Github-Repository, das die Quellcodes des Docker-Images enthält und dessen Verwendung beschreibt: https://github.com/SSLcom/ci-images 

Sample Gitlab CI Pipeline

Check out the sample Gitlab CI pipeline we have created on github.com/SSLcom/codesigner-gitlabci-sample

Andere CI/CD-Remote-Signatur-Integrationsleitfäden

Wenden Sie sich für Informationen zu einem eSigner-Abonnement und Codesignaturzertifikaten, einschließlich hochvolumiger und kundenspezifischer Lösungen, bitte an  oder füllen Sie das untenstehende Formular aus.  

Abonnieren Sie den Newsletter von SSL.com

Verpassen Sie keine neuen Artikel und Updates von SSL.com