Intégration de la signature de code dans le cloud avec GitLab CI

Variables d'environnement

• USERNAME: nom d'utilisateur du compte SSL.com. (Obligatoire)
• MOT DE PASSE: Mot de passe du compte SSL.com (Requis)
• CREDENTIAL_ID: ID d'identification pour la signature du certificat. Si credential_id est omis et que l'utilisateur n'a qu'un seul certificat de signature de code eSigner, CodeSignTool utilisera celui-ci par défaut. Si l'utilisateur possède plusieurs certificats de signature de code, ce paramètre est obligatoire. (Obligatoire)
• TOTP_SECRET: Secret OAuth TOTP. Vous pouvez accéder à des informations détaillées sur https://www.ssl.com/how-to/automate-esigner-ev-code-signing (Obligatoire)
• ENVIRONNEMENT_NAME : Environnement 'TEST' ou 'PROD'. (Obligatoire)

Contributions

• chemin_fichier_entrée: Chemin de l'objet code à signer. (Obligatoire)
• chemin_rép_sortie: Répertoire où le ou les objets de code signés seront écrits. Si output_path est omis, le fichier spécifié dans -file_path sera remplacé par le fichier signé.

Exemple de workflow de signature de DLL de code .NET

Créer un fichier yml

Regroupez les tâches en étapes. Tous les travaux d'une étape doivent être terminés avant l'exécution de l'étape suivante.

étapes : - construire - signer

Définissez les variables d'environnement globalement. La propriété au niveau du travail remplace les variables globales.

• Les variables d'environnement sont utilisées pour rendre les échantillons plus lisibles. Dans la capture d'écran ci-dessus de l'exemple de workflow, PROJECT_NAME, PROJECT_VERSION et DOTNET_VERSION ont éventuellement été omis. La signature peut toujours se poursuivre avec ces omissions.  
• Sous ENVIRONMENT_NAME, placez "TEST" pour la signature test et "PROD" pour la signature en direct.

variables : PROJECT_NAME : "HelloWorld" PROJECT_VERSION : "0.0.1" DOTNET_VERSION : "3.1" ENVIRONMENT_NAME : "PROD"

Définir la Étape de construction

Vous trouverez ci-dessous la définition de votre travail pour créer un artefact dll

build-dotnet :

1. Définissez à quelle étape le travail sera exécuté.

  étape : construire

2. Placez le nom complet de l'image qui doit être utilisée. Il doit contenir la partie Registre si nécessaire.

 image : mcr.microsoft.com/dotnet/sdk:3.1-bullseye

3. Définissez les scripts qui doivent s'exécuter *avant* le travail. Peut être défini globalement ou par travail.

avant_script : - mkdir -p ${CI_PROJECT_DIR}/artefacts - mkdir -p ${CI_PROJECT_DIR}/packages

4. Définissez les scripts Shell exécutés par le Runner. Créer un artefact 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/${ PROJECT_NAME}.dll

5. Spécifiez une liste de fichiers et de répertoires qui doivent être joints au travail s'il réussit.

• Le 'expire_in' permet de supprimer le fichier après un certain laps de temps. Son utilisation est facultative. C'est pourquoi la capture d'écran de l'exemple de workflow ci-dessus n'affiche pas cette propriété.

artefacts : chemins : - ${CI_PROJECT_DIR}/packages/HelloWorld.dll expire_in : 5 minutes

Définir l'étape du signe

Ci-dessous la définition de votre travail pour signer l'artefact dll

signe-dotnet-artefacts :

1. Définissez à quelle étape le travail sera exécuté.

  scène : signe

2. Placez le nom complet de l'image qui doit être utilisée. Il doit contenir la partie Registre si nécessaire.

 image : menu fixe : 19.03.0

3. Définir les services. Ceci est similaire à la propriété `image`, mais liera les services spécifiés au conteneur `image`.

services : - docker : 19.03.0-dind

4. Définissez des variables d'environnement pour des tâches spécifiques.

• Dans la capture d'écran ci-dessus, la commande sign a été définie directement dans le script sign et non sous les variables d'environnement. BLes deux méthodes peuvent signer correctement avec TravisCI.

  variables : COMMANDE : "signe"

5. Définissez les scripts qui doivent s'exécuter *avant* le travail. Peut être défini globalement ou par travail.

  avant_script : - mkdir -p ${CI_PROJECT_DIR}/artefacts - mkdir -p ${CI_PROJECT_DIR}/packages

6. Placez les scripts Shell exécutés par le Runner. Signer l'artefact dll .NET avec CodeSignTool Docker Image

script : - docker pull ghcr.io/sslcom/codedesigner: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/codedesigner:latest ${COMMAND} -input_file_path=/codesign/examples/${PROJECT_NAME}.dll -output_dir_path=/codesign/output

7. Ecrivez le script qui peut être utilisé pour spécifier une liste de fichiers et de répertoires qui doivent être attachés au travail s'il réussit.

artefacts : chemins : - ${CI_PROJECT_DIR}/artifacts/${PROJECT_NAME}.dll expire_in : 1 jours

8. Spécifiez une liste de noms de tâches d'étapes antérieures à partir desquelles les artefacts doivent être chargés.

dépendances : - build-dotnet

Lancer l'étape de construction

Créer un référentiel

Reportez-vous aux instructions de la ligne de commande sur Gitlab comme indiqué dans la capture d'écran ci-dessous

Poussez votre dossier

Faites-le en cliquant terminal au menu, suivi de Nouveau terminal.

Tapez le script push sur votre Terminal pour pousser le projet 

Cliquez sur le bouton Construire

Après avoir déclenché le pipeline, passez à la construction

Vérifier si la construction est réussie  

Initier l'étape de signature

Passez à la signature de l'artefact

Confirmer si la signature du code est réussie

Vous pouvez maintenant télécharger le fichier signé

Exemple de pipeline CI Gitlab

Autres guides d'intégration de la signature à distance CI/CD

• Intégration de la signature de code dans le cloud avec CircleCI
• Intégration de la signature de code dans le cloud avec les actions GitHub
• Intégration de la signature de code dans le cloud avec Jenkins CI
• Intégration de la signature de code dans le cloud avec Travis CI
• Intégration de la signature de code dans le cloud avec Azure DevOps
• Intégration de la signature de code dans le cloud avec BitBucket
• Automatisation de la signature de code dans le cloud avec les services CI/CD

Besoin de solutions personnalisées ? 

Grâce à nos connaissances spécialisées et à notre personnel d'assistance cinq étoiles, nous sommes prêts et disposés à travailler avec vous sur des solutions personnalisées ou des remises de signature de gros volumes au niveau de l'entreprise. Remplissez le formulaire ci-dessous et nous vous contacterons.