Verständnisfrage zur Action "Check certificate policies" in smime-ca-bundle

[869288141]

Hallo NoSpamProxy Team,
ich habe mir euer Repository smime-ca-bundle (Link) und insbesondere die Action "Check certificate policies" angesehen.
Dabei bin ich auf einen Punkt gestoßen, den ich bisher nicht ganz nachvollziehen kann.

Im Workflow gibt es folgenden Step:

- name: Check PEM encoding
  env:
    ALL_CHANGED_FILES: ${{ steps.changed-files.outputs.all_changed_files }}
  run: |
    # check PEM encoding
    if [[ ${ALL_CHANGED_FILES} -ne 0 ]]
    then
      # do not fail check if no certificate was added or changed
      exit
    fi

    openssl version
    set +e
    fail=false
    for file in ${ALL_CHANGED_FILES}; do
      openssl x509 -noout -inform PEM -in "$(echo "$file" | sed 's@\\@@g')"
      if [[ $? -ne 0 ]]
      then
        echo "::error file=$file::$file is not PEM encoded."
        fail=true
      fi
    done

    if [[ "$fail" == true ]]
    then
      echo "At least one certificate was not PEM encoded."
      exit 1
    fi

Wie zu sehen ist, wird die Variable $fail auf true gesetzt, sobald mindestens eine Datei nicht im PEM-Format vorliegt.

Der darauffolgende Step sieht folgendermaßen aus:

- name: Check file name and location
  if: always()

Am Ende dieses Steps gibt es erneut eine Abfrage in Bash:

...
if ($fail -eq $true) {
    echo "At least one certificate is in a wrong location."
    exit 1
}

Für mich ist das aktuell nicht ganz klar: Sollte der zweite Step nicht nur ausgeführt werden, wenn $fail im vorherigen Step false war?
Vielen Dank vorab für eine kurze Erklärung!


Gruß,
Daniel

 

[JanJäschke]

Hallo Daniel,

Prinzipiell könnte man das machen und wäre im Normalfall auch effizienter.

Derzeit bringt das Vorgehen aber zwei Vorteile:
1. ich musste mich nicht darum kümmern das der zweite Step die verarbeiteten Daten vom ersten kennt, vermutlich nicht aufwändig, aber ich muss hier auch für mich zeitlich effizient sein da es „nur nebenbei“ bearbeitet wird
2. man bekommt immer den Output für beides und weiß (falls man z.b. manuell ein Zertifikat platziert hat) wo ein Fehler unterlaufen ist.

LG
Jan

 

[869288141]

Hallo Jan,
Danke für die Erläuterungen zu meinen Fragen.

1. ich musste mich nicht darum kümmern das der zweite Step die verarbeiteten Daten vom ersten kennt, vermutlich nicht aufwändig, aber ich muss hier auch für mich zeitlich effizient sein da es „nur nebenbei“ bearbeitet wird

ich überlege gerade, wie man das Handling von Zertifikaten in einem CI-Job effizienter gestalten kann. Mein aktueller Ansatz ist, die Verarbeitung nicht in zwei separaten Steps, sondern in einem Step abzubilden. Soweit ich es bisher verstanden habe, sind die beiden Steps bidirektional voneinander abhängig.

2. man bekommt immer den Output für beides und weiß (falls man z.b. manuell ein Zertifikat platziert hat) wo ein Fehler unterlaufen ist.

Wäre es eine praktikable Lösung, das neue Zertifikat zunächst in ein Upload-Verzeichnis (z. B. upload) zu legen? Beim Erstellen eines Pull Requests könnte dann ein Workflow das Zertifikat gemäß den Vorgaben verschieben und umbenennen. Damit verbunden die einzelnen Schritte mit Commits im Pull Request dokumentieren.


Gruß,
Daniel