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.

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

Il s'agit d'un didacticiel expliquant comment effectuer une signature de code automatisée sur GitLab CI à l'aide d'eSigner CodeSignTool. 

CodeSignTool est un utilitaire de ligne de commande sécurisé qui fait partie d'eSigner : notre environnement de signature de code dans le cloud qui profite aux éditeurs et aux développeurs de logiciels grâce à sa capacité à effectuer la signature à distance de manière sûre et efficace de manière simple.  L'exemple de flux de travail ci-dessous montre un code DLL .NET en cours de signature sur GitLab CI avec eSigner.

SSL.com EV Signature du code Les certificats aident à protéger votre code contre les falsifications non autorisées et les compromis avec le plus haut niveau de validation, et sont disponibles pour aussi peu que 249 $ par année. Vous pouvez également utilisez votre certificat EV Code Signing à grande échelle dans le cloud avec eSigner.

COMMANDEZ

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

  • input_file_path: Chemin de l'objet code à signer. (Obligatoire)
  • output_dir_path: 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

 

  1. 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

 

  1. 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

 

  1. 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

 

  1. 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

 

  1. 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

 

  1. 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

 

  1. 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"

 

  1. 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

 

  1. Placez les scripts Shell exécutés par le Runner. Signer l'artefact dll .NET avec CodeSignTool Docker Image
script : - docker pull ghcr.io/bayrakmustafa/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/bayrakmustafa/codedesigner:latest ${COMMAND} -input_file_path=/codesign/examples/${PROJECT_NAME}.dll -output_dir_path=/codesign/output

 

  1. 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

 

  1. 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é

Remarque : Assurez-vous de corriger les erreurs typographiques ou les sauts de ligne erronés dans le script afin que le processus de signature se déroule sans heurts.

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

Pour plus d'informations sur un abonnement eSigner et des certificats de signature de code, y compris des solutions à volume élevé et personnalisées, veuillez contacter  Ou remplissez le formulaire ci-dessous.  

Abonnez-vous à la newsletter de SSL.com

Ne manquez pas les nouveaux articles et mises à jour de SSL.com