Schlagwort: GitHub

secrethubwarden – Secrets von Bitwarden zu GitHub synchronisieren

Bitwarden ist aktuell mein persönlicher Passwortmanager. Und meine privaten Projekte deploye ich bevorzugt über GitHub Actions. Dabei verwende ich Repository Secrets um sensitive Daten wie Passwörter oder Secret Keys sicher abzulegen. Das manuelle Herumkopieren dieser Daten ist allerdings fehleranfällig und hätte ich gerne automatisiert. Eine existierende Lösung für mein Problem fand ich nicht, dafür ein Projekt mit ähnlicher Funktionalität: envwarden. Davon inspiriert habe ich mir ein eigenes Skript geschrieben und veröffentlicht:

secrethubwarden

(Habe ich an dieser Stelle schon mal erwähnt, dass ich schlecht im Namen vergeben bin?)

Dieses Bash-Skript nimmt die Konfigurationsdatei .secrethubwarden mit folgendem Format:

MY_SECRET_PASSWORD=secrethubwarden Example Password
MY_SECRET_NOTE=Secret Note Name

Danach benutzt es die Bitwarden-CLI um im Passwort-Vault das entsprechende Passwort (z.B. secrethubwarden Example Password) zu suchen, und schreibt dieses mit der GitHub-CLI als Repository Secret (Hier: MY_SECRET_PASSWORD) hinein. Ohne dass du dein Passwort je zu Gesicht bekommst.

Ich benutze secrethubwarden bereits erfolgreich in verschiedenen Projekten. Es ist etwas langsam, aber es nimmt mir viel Handarbeit ab. Und animiert mich damit dazu sensitive Daten noch konsequenter aus dem Sourcecode rauszuhalten.

Feedback ist willkommen.

GitHub Action: Mehrzeiliges Secret in eine Datei schreiben

Um beispielsweise eine .env-Datei in einer GitHub Action aus einem Secret heraus zu befüllen, muss sich leider mit fehlenden Zeilenumbrüche herumschlagen.

Ein einfacher Trick habe ich in einem Stackoverflow-Kommentar gefunden: Die unerwünschten Leerzeichen mit tr in Newlines verwandeln.

- name: Write .env
  run: |
    echo $ENV_FILE | tr ' ' '\n' > .env
  shell: bash
  env:
    ENV_FILE: ${{secrets.DOTENV}}

Nachteil dieser Methode: Das Secret selber darf keine Leerzeichen enthalten.

GitHub Action: Apprise-Notifikationen

Beim Experimentieren mit der Beta-Version von GitHub Actions (Einem Tool für Build-Prozesse, Continous Integration, Deployment etc.) wollte ich mir Notifikationen aus Pipelines zukommen lassen. Zwar gab es schon einige Actions welche mit einzelnen Services funktionierten, aber jede dieser Action war unterschiedlich zu konfigurieren und benutzen.

Kurzerhand habe ich mich durch die lückenhafte Dokumentation gekämpft und eine eigene generelle Notifikation-Action erstellt: Apprise-GA.

Dank der Python-Bibliothek Apprise kann diese Action Nachrichten an Dutzende verschiedene Services schicken: Slack, Discord, IFTTT, Matrix, Telegram, Twitter, Pushover etc. etc.

Und mit dem Einsatz von Templates können auch dynamische Texte verschickt werden:

action "Send push notification" {
  uses = "cstuder/apprise-ga@master"
  secrets = ["APPRISE_URL"]
  args = [
    "Push received on {{ ref }}",
    "Commit by {{ head_commit.author.name }}: {{ head_commit.message | truncate(128) }} ({{ head_commit.id[0:7] }})"]
}

Ich finde meine Action überzeugt.

Dokumentation auf GitHub: https://github.com/cstuder/apprise-ga

SVN vs. Git: 1 zu 3

An meinem Arbeitsplatz benutze ich täglich das VersionskontrollsystemSubversion und bin eigentlich glücklich damit. Seit einiger Zeit spiele ich in meiner Freizeit mit der Alternative Git herum und konnte mich zuerst nicht wirklich damit anfreuden. Mittlerweile habe ich gemerkt, woran das lag: Ich fühle mich erst wirklich sicher, wenn mein Code auf zwei Maschinen existiert (Lokal und in einem entfernten Repository). Bei Subversion funktioniert das folgendermassen:

svn commit

Bei Git hingegen, sind dafür drei Befehle notwendig:

git add
git commit
git push

Der dreifache Aufwand für dasselbe Resultat. Es existieren zwar Abkürzungen, aber dann verpasst man die eigentliche Idee an der Add & Commit-Konstruktion: Spezifischere Commits ohne die beliebte Allerweltsnachricht ‚Diverse Änderungen‘.

Mittlerweile bin ich etwas vertrauter mit dem Umgang und beginne Git zu schätzen. Letzte Woche wagte ich sogar schon in fremden Code einen Fehler zu korrigieren und einen Pull-Request abzusetzen. Auch wenn das betroffene Projekt kaum Aktivität zeigt, freue ich mich doch über die Möglichkeit, derart einfach an einem Projekt mitzuwirken. Git und Github sind wunderbare Werkzeuge für Open Source.