Integrazione Cloud Code Signing con GitLab CI

Questo è un tutorial su come eseguire la firma automatica del codice su GitLab CI utilizzando eSigner CodeSignTool. 

CodeSignTool è un'utilità della riga di comando sicura che fa parte di eSigner: il nostro ambiente di firma del codice cloud che avvantaggia gli editori e gli sviluppatori di software con la sua capacità di condurre in modo sicuro ed efficiente la firma del codice aziendale senza complicazioni.  Il flusso di lavoro di esempio seguente mostra un codice DLL .NET firmato su GitLab CI con eSigner.

SSL.com's EV Firma del codice i certificati aiutano a proteggere il tuo codice da manomissioni e compromissioni non autorizzate con il massimo livello di convalida e sono disponibili a partire da $ 249 all'anno. È anche possibile usa il tuo certificato EV Code Signing su larga scala nel cloud utilizzando eSigner.

ORDINA SUBITO

variabili ambientali

  • USERNAME: nome utente dell'account SSL.com. (Necessario)
  • PASSWORD: password dell'account SSL.com (richiesto)
  • CREDENZIALE_ID: ID credenziale per la firma del certificato. Se credential_id viene omesso e l'utente dispone di un solo certificato di firma del codice eSigner, CodeSignTool verrà impostato automaticamente su quello. Se l'utente ha più di un certificato di firma del codice, questo parametro è obbligatorio. (Necessario)
  • TOTP_SEGRETO: Segreto TOTP OAuth. È possibile accedere a informazioni dettagliate su https://www.ssl.com/how-to/automate-esigner-ev-code-signing (Obbligatorio)
  • NOME_AMBIENTE : Ambiente 'TEST' o 'PROD'. (Necessario)

ingressi

  • percorso_file_input: Percorso dell'oggetto codice da firmare. (Necessario)
  • output_dir_percorso: Directory in cui verranno scritti gli oggetti codice firmato. Se output_path viene omesso, il file specificato in -file_path verrà sovrascritto con il file firmato.

Flusso di lavoro di esempio di firma della DLL del codice .NET

Crea un file yml

Raggruppa i lavori in più fasi. Tutti i lavori in una fase devono essere completati prima dell'esecuzione della fase successiva.

fasi: - costruire - firmare
 

Definire le variabili d'ambiente a livello globale. La proprietà a livello di lavoro ha la precedenza sulle variabili globali.

  • Le variabili di ambiente vengono utilizzate per rendere i campioni più leggibili. Nello screenshot sopra del flusso di lavoro di esempio, PROJECT_NAME, PROJECT_VERSION e DOTNET_VERSION sono stati opzionalmente omessi. La firma può comunque procedere con queste omissioni.  
  • In ENVIRONMENT_NAME, inserisci "TEST" per la firma del test e "PROD" per la firma dal vivo.
variabili: PROJECT_NAME: "HelloWorld" PROJECT_VERSION: "0.0.1" DOTNET_VERSION: "3.1" ENVIRONMENT_NAME: "PROD"
 

Definire il Fase di costruzione

Di seguito è riportata la definizione del tuo lavoro per creare artefatto dll

build-dotnet:

 

  1. Definisci in quale fase verrà eseguito il lavoro.
  fase: costruire

 

  1. Inserisci il nome completo dell'immagine che dovrebbe essere utilizzata. Dovrebbe contenere la parte del Registro di sistema, se necessario.
 immagine: mcr.microsoft.com/dotnet/sdk:3.1-bullseye

 

  1. Definisci gli script che dovrebbero essere eseguiti *prima* del lavoro. Può essere impostato a livello globale o per lavoro.
prima_script: - mkdir -p ${CI_PROJECT_DIR}/artifacts - mkdir -p ${CI_PROJECT_DIR}/pacchetti

 

  1. Definisci gli script Shell eseguiti dal Runner. Crea artefatto DLL
script: - dotnet build dotnet/${PROJECT_NAME}.csproj -c Release - cp dotnet/bin/Release/netcoreapp${DOTNET_VERSION}/${PROJECT_NAME}-${PROJECT_VERSION}.dll ${CI_PROJECT_DIR}/packages/${ NOME_PROGETTO}.dll

 

  1. Specificare un elenco di file e directory che devono essere allegati al lavoro se riesce.
  • Il 'scade_in' consente di eliminare il file dopo un certo periodo di tempo. Il suo utilizzo è facoltativo. Questo è il motivo per cui lo screenshot del flusso di lavoro di esempio sopra non mostra questa proprietà.
artefatti: percorsi: - ${CI_PROJECT_DIR}/packages/HelloWorld.dll scadono_in: 5 minuti
 

Definisci la fase dei segni

Di seguito è riportata la definizione del tuo lavoro per firmare artefatto dll

sign-dotnet-artefatti:

 

  1. Definisci in quale fase verrà eseguito il lavoro.
  stadio: segno

 

  1. Inserisci il nome completo dell'immagine che dovrebbe essere utilizzata. Dovrebbe contenere la parte del Registro di sistema, se necessario.
 immagine: finestra mobile:19.03.0

 

  1. Definisci i servizi. È simile alla proprietà `image`, ma collegherà i servizi specificati al contenitore `image`.
servizi: - docker:19.03.0-dind

 

  1. Definire le variabili di ambiente per lavori specifici.
  • Nello screenshot sopra, il comando sign è stato definito direttamente nello script sign e non nelle variabili di ambiente. Baltri metodi possono firmare correttamente con TravisCI.
  variabili: COMANDO: "segno"

 

  1. Definisci gli script che dovrebbero essere eseguiti *prima* del lavoro. Può essere impostato a livello globale o per lavoro.
  prima_script: - mkdir -p ${CI_PROJECT_DIR}/artifacts - mkdir -p ${CI_PROJECT_DIR}/pacchetti

 

  1. Posiziona gli script Shell eseguiti dal Runner. Firma l'artefatto .NET dll con 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. Scrivere lo script che può essere utilizzato per specificare un elenco di file e directory che devono essere allegati al lavoro se ha esito positivo.
artefatti: percorsi: - ${CI_PROJECT_DIR}/artifacts/${PROJECT_NAME}.dll scadono_in: 1 giorni

 

  1. Specificare un elenco di nomi lavoro dalle fasi precedenti da cui caricare gli artefatti.
dipendenze: - build-dotnet

SSL.com's EV Firma del codice i certificati aiutano a proteggere il tuo codice da manomissioni e compromissioni non autorizzate con il massimo livello di convalida e sono disponibili a partire da $ 249 all'anno. È anche possibile usa il tuo certificato EV Code Signing su larga scala nel cloud utilizzando eSigner.

ORDINA SUBITO

Avvia la fase di costruzione

Crea un archivio

Fare riferimento alle istruzioni della riga di comando su Gitlab come mostrato nello screenshot seguente

Spingi la tua cartella

Fallo facendo clic terminal nel menu, seguito da Nuovo terminale.

Digita lo script push sul tuo terminale per eseguire il push del progetto 

Fare clic sul pulsante Crea

Dopo aver attivato la pipeline, procedere con la compilazione

Verifica se la compilazione ha esito positivo  

Avvia la fase dei segni

Procedi a firmare il manufatto

Conferma se la firma del codice ha esito positivo

Ora puoi scaricare il file firmato

È possibile fare riferimento a SSL.com Repository Github che contiene i codici sorgente dell'immagine docker e descrive come usarlo: https://github.com/SSLcom/ci-images 

Esempio di pipeline Gitlab CI

Dai un'occhiata alla pipeline Gitlab CI di esempio che abbiamo creato github.com/SSLcom/codesigner-gitlabci-sample

Altre guide all'integrazione della firma remota CI/CD

Hai bisogno di soluzioni personalizzate? 

Con la nostra conoscenza esperta e il personale di supporto a cinque stelle, siamo pronti e disposti a lavorare con te su soluzioni personalizzate o sconti per firme di alto volume a livello aziendale. Compila il modulo sottostante e sarai ricontattato.

Iscriviti alla newsletter di SSL.com

Non perdere nuovi articoli e aggiornamenti da SSL.com

Rimani informato e sicuro

SSL.com è un leader globale nella sicurezza informatica, PKI e certificati digitali. Iscriviti per ricevere le ultime notizie del settore, suggerimenti e annunci di prodotti da SSL.com.

Ci piacerebbe il tuo feedback

Partecipa al nostro sondaggio e facci sapere cosa ne pensi del tuo recente acquisto.