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.

Integracja Cloud Code Signing z GitLab CI

To jest samouczek dotyczący automatycznego podpisywania kodu w GitLab CI za pomocą eSigner CodeSignTool. 

CodeSignTool to bezpieczne narzędzie wiersza poleceń, które stanowi część eSigner: naszego środowiska do podpisywania kodu w chmurze, które przynosi korzyści wydawcom oprogramowania i programistom dzięki możliwości bezpiecznego i wydajnego przeprowadzania zdalnego podpisywania w nieskomplikowany sposób.  Poniższy przykładowy przepływ pracy przedstawia kod .NET DLL podpisany w GitLab CI za pomocą eSigner.

SSL.com's EV Podpisywanie kodu Certyfikaty pomagają chronić Twój kod przed nieautoryzowanym manipulowaniem i naruszeniem bezpieczeństwa z najwyższym poziomem walidacji i są dostępne za jedyne $ 249 rocznie. Można również używaj swojego certyfikatu EV Code Signing na dużą skalę w chmurze za pomocą eSigner.

ZAMÓW TERAZ

Zmienne środowiskowe

  • USERNAME: Nazwa użytkownika konta SSL.com. (Wymagany)
  • HASŁO: Hasło do konta SSL.com (wymagane)
  • CREDENTIAL_ID: Identyfikator poświadczeń do podpisywania certyfikatu. Jeśli credential_id zostanie pominięty, a użytkownik ma tylko jeden certyfikat podpisywania kodu eSigner, CodeSignTool domyślnie to zrobi. Jeśli użytkownik ma więcej niż jeden certyfikat podpisywania kodu, ten parametr jest obowiązkowy. (Wymagany)
  • TOTP_SECRET: Klucz tajny TOTP protokołu OAuth. Możesz uzyskać dostęp do szczegółowych informacji na temat https://www.ssl.com/how-to/automate-esigner-ev-code-signing (Wymagany)
  • ŚRODOWISKO_NAME : 'TEST' lub 'PROD' Środowisko. (Wymagany)

Wejścia

  • ścieżka_pliku_wejściowego: Ścieżka obiektu kodu do podpisania. (Wymagany)
  • ścieżka_katalogu_wyjściowego: Katalog, w którym zostaną zapisane obiekty z podpisanym kodem. Jeśli ścieżka_wyjściowa zostanie pominięta, plik określony w -ścieżka_pliku zostanie zastąpiony podpisanym plikiem.

Przykładowy przepływ pracy z podpisywaniem biblioteki DLL kodu .NET

Utwórz plik yml

Grupuj zadania w etapy. Wszystkie prace w jednym etapie muszą zostać zakończone przed wykonaniem kolejnego etapu.

etapy: - budowa - znak
 

Zdefiniuj zmienne środowiskowe globalnie. Właściwość poziomu zadania zastępuje zmienne globalne.

  • Zmienne środowiskowe są używane, aby próbki były bardziej czytelne. Na powyższym zrzucie ekranu przykładowego przepływu pracy opcjonalnie pominięto PROJECT_NAME, PROJECT_VERSION i DOTNET_VERSION. Podpisywanie może nadal przebiegać z tymi pominięciami.  
  • W sekcji ENVIRONMENT_NAME umieść „TEST” dla podpisywania testowego i „PROD” dla podpisywania na żywo.
zmienne: PROJECT_NAME: „HelloWorld” PROJECT_VERSION: „0.0.1” DOTNET_VERSION: „3.1” ENVIRONMENT_NAME: „PROD”
 

Zdefiniuj Etap budowy

Poniżej znajduje się definicja twojej pracy polegającej na zbudowaniu artefaktu dll

build-dotnet:

 

  1. Określ, na jakim etapie zadanie zostanie uruchomione.
  etap: budowa

 

  1. Umieść pełną nazwę obrazu, który ma zostać użyty. W razie potrzeby powinien zawierać część rejestru.
 obraz: mcr.microsoft.com/dotnet/sdk:3.1-bullseye

 

  1. Zdefiniuj skrypty, które powinny zostać uruchomione *przed* zadaniem. Można ustawić globalnie lub na zadanie.
before_script: - mkdir -p ${CI_PROJECT_DIR}/artifacts - mkdir -p ${CI_PROJECT_DIR}/pakiety

 

  1. Zdefiniuj skrypty powłoki wykonywane przez Runnera. Zbuduj artefakt DLL
skrypt: - 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. Określ listę plików i katalogów, które powinny być dołączone do zadania, jeśli się powiedzie.
  • "wygasa_wWłaściwość ' umożliwia usunięcie pliku po określonym czasie. Jego użycie jest opcjonalne. Dlatego zrzut ekranu przykładowego przepływu pracy powyżej nie pokazuje tej właściwości.
artefakty: ścieżki: - ${CI_PROJECT_DIR}/packages/HelloWorld.dll wygasa_za: 5 minut
 

Zdefiniuj etap podpisywania

Poniżej znajduje się definicja twojego zadania do podpisania artefaktu dll

artefakty znak-dotnet:

 

  1. Określ, na jakim etapie zadanie zostanie uruchomione.
  etap: znak

 

  1. Umieść pełną nazwę obrazu, który ma zostać użyty. W razie potrzeby powinien zawierać część rejestru.
 obraz: okno dokowane: 19.03.0

 

  1. Zdefiniuj usługi. Jest to podobne do właściwości `image`, ale łączy określone usługi z kontenerem `image`.
usługi: - docker:19.03.0-dind

 

  1. Zdefiniuj zmienne środowiskowe dla określonych zadań.
  • Na powyższym zrzucie ekranu polecenie podpisu zostało zdefiniowane bezpośrednio w skrypcie podpisu, a nie pod zmiennymi środowiskowymi. Binne metody mogą poprawnie podpisywać się za pomocą TravisCI.
  zmienne: POLECENIE: "znak"

 

  1. Zdefiniuj skrypty, które powinny zostać uruchomione *przed* zadaniem. Można ustawić globalnie lub na zadanie.
  before_script: - mkdir -p ${CI_PROJECT_DIR}/artifacts - mkdir -p ${CI_PROJECT_DIR}/pakiety

 

  1. Umieść skrypty powłoki wykonywane przez Runnera. Podpisz artefakt biblioteki .NET dll za pomocą obrazu Docker CodeSignTool
skrypt: - 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 ghcr.io/bayrakmustafa/codesigner:latest ${COMMAND} -input_file_path=/codesign/examples/${PROJECT_NAME}.dll -output_dir_path=/codesign/output

 

  1. Napisz skrypt, którego można użyć do określenia listy plików i katalogów, które powinny być dołączone do zadania, jeśli się powiedzie.
artefakty: ścieżki: - ${CI_PROJECT_DIR}/artifacts/${PROJECT_NAME}.dll wygasa_in: 1 dni

 

  1. Określ listę nazw zadań z wcześniejszych etapów, z których mają być ładowane artefakty.
zależności: - build-dotnet
 

Rozpocznij etap budowania

Utwórz repozytorium

Zapoznaj się z instrukcjami wiersza poleceń na Gitlab, jak widać na poniższym zrzucie ekranu

Prześlij swój folder

Zrób to, klikając terminal w menu, a następnie Nowy terminal.

Wpisz skrypt push na swoim terminalu, aby przesłać projekt 

Kliknij przycisk Buduj

Po uruchomieniu potoku przejdź do kompilacji

Sprawdź, czy kompilacja się powiodła  

Rozpocznij etap podpisywania

Przejdź do podpisania artefaktu

Potwierdź, czy podpisywanie kodu powiodło się

Możesz teraz pobrać podpisany plik

Uwaga: Upewnij się, że poprawiłeś błędy typograficzne lub błędne podziały wierszy w skrypcie, aby proces podpisywania przebiegał płynnie.

Inne przewodniki integracji zdalnego podpisywania CI/CD

Aby uzyskać informacje na temat subskrypcji eSigner i certyfikatów podpisywania kodu, w tym rozwiązań niestandardowych i na dużą skalę, skontaktuj się z  lub wypełnij poniższy formularz.  

Zapisz się do newslettera SSL.com

Nie przegap nowych artykułów i aktualizacji z SSL.com