Druckerkonfiguration sicher versionieren – ohne Zugangsdaten
08.10.2026
Druckerprofile und Änderungen lassen sich gemeinsam pflegen, ohne Netzwerkzugänge mitzuveröffentlichen. Entscheidend ist, exportierte Konfigurationen auf enthaltene Zugangsdaten zu prüfen, private Dateien vom Repository auszuschließen und einen versehentlich veröffentlichten Schlüssel sofort zu widerrufen oder zu erneuern.
Erst trennen: Druckprofil ist nicht gleich Druckerzugang
Eine Konfiguration kann aus unkritischen Prozesswerten und vertraulichen Verbindungsdaten bestehen. Bei PrusaSlicer ist der Unterschied praktisch sichtbar: Der Export „Config Bundle with Physical Printers“ ergänzt das Paket ausdrücklich um API-Schlüssel und IP-Adresse. Ein solches Paket ist daher nicht automatisch ein unbedenkliches Archiv für ein Repository. Prüfen Sie vor dem Commit, welche Exportoption verwendet wurde und was tatsächlich in der Datei steht. Versionieren Sie Profile, die Düse, Material, Temperatur, Geschwindigkeit oder Druckbett beschreiben; halten Sie Netzwerkadresse und Authentisierung getrennt. Eine IP-Adresse ist nicht immer ein Geheimnis, kann aber interne Infrastruktur offenlegen.
Ein Repository-Muster, das Änderungen nachvollziehbar hält
Legen Sie im Repository nur die gemeinsame, übertragbare Konfiguration ab. Ein einfaches Muster ist etwa: ```text printer-setup/ profiles/ # freigegebene Profile und dokumentierte Änderungen connection.example # leere Vorlage, keine echten Schlüssel .gitignore ``` Die tatsächliche Verbindungsdatei und lokale Exporte mit Zugangsdaten gehören außerhalb des Commits. Ergänzen Sie die passenden Dateinamen in `.gitignore`, etwa `connection.local` oder `private-export.ini`, und versionieren Sie diese Ignore-Regel selbst, damit sie auch beim Klonen gilt. Das schützt nur Dateien, die noch nicht verfolgt werden: Git weist ausdrücklich darauf hin, dass Ignore-Regeln bereits getrackte Dateien nicht ausblenden. Ein einmal versehentlich hinzugefügtes Paket wird also nicht dadurch sicher, dass später eine Ignore-Zeile hinzukommt.
Vor dem Commit prüfen, statt dem Dateinamen vertrauen
Behandeln Sie Dateinamen wie `backup.ini`, `printer-export` oder `settings` nicht als Sicherheitsmerkmal. Öffnen Sie den Export vor dem Einchecken und suchen Sie nach Feldern, die Schlüssel, Passwörter, Tokens oder direkte Verbindungsdaten enthalten könnten. Nutzen Sie für die gemeinsame Ablage eine bereinigte Konfiguration oder eine Vorlage mit erklärenden Platzhaltern; echte Werte werden lokal ergänzt. Wenn eine Datei bereits im Git-Index liegt, reicht das spätere Ignorieren nicht: Git dokumentiert `git rm --cached <Datei>` als Weg, die Datei aus dem Index zu nehmen, ohne damit die lokale Arbeitskopie zu löschen. Prüfen Sie anschließend den geplanten Commit und seinen Dateiinhalt, bevor Sie ihn teilen. Das ist eine nachvollziehbare Routine, keine Garantie gegen jeden Geheimnis-Leak.
Wenn ein Schlüssel doch veröffentlicht wurde
Gehen Sie davon aus, dass ein öffentlich gewordener Schlüssel kompromittiert sein kann. Widerrufen oder erneuern Sie zuerst das betroffene Passwort, den Token oder API-Schlüssel und prüfen Sie, ob der Dienst unbefugte Zugriffe verzeichnet. Ein neuer Commit, der den Text entfernt, macht einen bereits offengelegten Schlüssel nicht wieder sicher. Danach können Sie klären, ob eine Bereinigung der Git-Historie nötig ist. Das Umschreiben der Historie ist ein separater Eingriff: Klone anderer Personen können weiterhin alte Fassungen enthalten, und eine schlecht koordinierte Bereinigung kann die Daten wieder einführen. Deshalb sollten Beteiligte ihre Kopien und den Umgang mit Branches abstimmen. Für einen einzelnen privaten Projektordner kann Rotation plus Entfernung aus dem aktuellen Stand genügen; bei öffentlichem oder gemeinsam genutztem Repository muss die Reichweite sorgfältiger bewertet werden.