GitHub Action zur automatisierten Pflege des smime-ca-bundle

[869288141]

Hallo Jan,
hallo Stefan,
es geht um das Projekt smime-ca-bundle, das ihr in eurem gleichnamigen GitHub-Repository bereitstellt (Link).
Aktuell befinden sich dort über 50 Zertifikate, die zum jetzigen Zeitpunkt (11.01.2026, 18:36 Uhr MEZ) bereits abgelaufen sind.

Um euch, und auch uns als Nutzer, die Pflege zu erleichtern, würde ich gerne eine GitHub Action beisteuern. Diese soll die enthaltenen Zertifikate automatisiert auslesen, deren Gültigkeit prüfen und abgelaufene Zertifikate ggf. entfernen. Anschließend würde ein separater Branch erstellt, pro entferntem Zertifikat ein eigener Commit erzeugt und zum Schluss ein Pull Request eröffnet werden.

Bevor ich damit starte, würde mich interessieren, ob es von eurer Seite bestimmte Rahmenbedingungen oder Wünsche gibt, die berücksichtigt werden sollten. Ein denkbares Beispiel wäre eine Karenzzeit von z.B. drei Monaten nach Ablauf des Zertifikats, bevor es entfernt wird.

Feedback dazu ist sehr willkommen.


Gruß,
Daniel

 

[JanJäschke]

Hallo Daniel,

das klingt klasse
Rahmenbedingungen gibt es keine, deine Beschreibung klingt eigentlich ganz gut
Karrenz ist nicht notwendig, wenn abgelaufen, dann ist abgelaufen. Die müssen auch nicht mehr ausgerollt werden.


LG
Jan

 

[869288141]

Hallo Jan,
die erste Fassung ist inzwischen fertiggestellt und befindet sich aktuell im QM.

Im Zuge der Entwicklung sind bei mir folgende Fragen aufgekommen:

1. Sicherheitskonzept: Wie hoch priorisiert ihr das Thema Sicherheit? Konkret stellt sich für mich die Frage, ob ein klassischer PAT aus eurer Sicht ausreichend ist oder ob ihr eine Umsetzung mittels GitHub App (inkl. App ID und Private Key) bevorzugt.
   
   
2. Verwendung von GitHub Actions / Updates: Alle verwendeten Actions aus dem Marketplace sind aktuell per SHA-Hash gepinnt. Mir ist aufgefallen, dass es derzeit keine Dependabot-Konfiguration in eurem Repository gibt. Wie ist hierzu euer Plan? Meinen Pull Request vom 02.12.2025 habt ihr bis dato nicht kommentiert.
   
   Da auch eure bestehenden Workflows auf feste SHAs setzen, würden diese ohne Dependabot künftig vermutlich nicht automatisch aktualisiert werden.
   
   
3. Bei jedem Pull Request wird aktuell die Action „Check certificate policies“ getriggert. In der derzeitigen Implementierung hat das zwar keinen funktionalen Impact, stellt aus meiner Sicht aber einen unnötigen Ressourcenverbrauch dar und kann optimiert werden. Eine (von mehreren) Idee ist, konsequent Labels zu verwenden?! Ist übersichtlich und einfach zu handeln.

Freue mich auf dein Feedback und deine Einschätzung dazu.


Gruß,
Daniel

 

[JanJäschke]

Hallo Daniel,

1. wäre ich stark für "GITHUB_TOKEN", das ist meines Wissens nach der Standard für Actions wenn Zugriffe gewährt werden müssen.
2. Hier bin ich noch nicht zu gekommen mir das in ruhe anzuschauen, da es sich aber um keine kritischen Themen handelt ist derzeit der Bedarf nicht vorhanden direkt die Zeit zu investieren. Die Aktion macht das was sie soll sauber und zuverlässig und das sollte sie auch in Zukunft entsprechend hinbekommen auf dem gepinnten Hash ^^
3. Danke für den input, das wurde tatsache einfach nicht bedacht. Wäre aber natürlich praktisch nur bei notwendigen die Aktion zu starten um auch die Zeit zu sparen.


LG
Jan

 

[869288141]

Hallo Jan,
gerne gebe ich dir Feedback auf die verschiedenen Punkte.

1. Bei der Verwendung von GitHub Apps wird zur Laufzeit ein GitHub Token erzeugt, das technisch einem PAT entspricht. Ich kenne euer GitHub-Setup nicht. Aber ich vermute, dass es sich bei nospamproxy um eine Organisation handelt. Das hätte zur Folge, dass ein PAT immer an einen Benutzer gebunden ist.
   
   Eine GitHub App kann man dagegen mit einem Service-Account unter Windows bzw. Active Directory vergleichen. Der generierte Token zur Laufzeit ist nur eine Stunde gültig und die Berechtigungen lassen sich sehr granular steuern -> Minimalprinzip.
   
   Sicherheitsbetrachtung: Bei GitHub Apps ist sie hoch, bei einem PAT aktuell eher mittel bis hoch riskant.
   Praktische Erfahrung: Wann immer möglich, werden heute GitHub Apps bevorzugt eingesetzt.
   
   Am Ende hast du natürlich das letzte Wort.
   
   
2. Ich würde GitHub Actions regelmäßig updaten, aus drei Gründen:
   Sicherheit: Alte Versionen können Lücken haben, über die jemand Code ausführen oder Secrets abgreifen könnte.
   Stabilität: GitHub passt die Laufzeitumgebungen an. Da kann eine alte Action plötzlich Probleme machen.
   
   Einerseits bietet ihr moderne Sicherheitsprodukte mit aktuellen Funktionen an, andererseits gibt es öffentliche Repos auf GitHub, die noch veraltete Actions nutzen. Das könnte bei Kunden schon für etwas Stirnrunzeln sorgen.
   
   Aber aktuell sind die gepinnten Versionen up-to-date.
   
   
3. Bisher habe ich das Label „Remove CA“ verwendet. Das Gegenstück könnte „Add CA“ sein. Ich freue mich aber auf weitere Vorschläge von euch.
   
   
4. Bezüglich der Dokumentation, sowohl der Voraussetzungen als auch der Funktionsweise: Soll ich eine README.md erstellen oder die Infos direkt als Kommentar in der YAML-Datei der Action hinzufügen?

Gruß,
Daniel