openSUSE nimmt ZUPT auf: Backups mit Post-Quanten-Verschlüsselung
openSUSE hat das Backup-Werkzeug ZUPT in Factory aufgenommen. Es verschlüsselt mit AES-256 und optional hybrid mit ML-KEM-768 und X25519. Offene Punkte: kein unabhängiges Audit, unklare Lizenzangabe im Paket, Versionsstand 5.2.9 gegenüber 5.2.10 im Repository.
openSUSE hat das Backup-Werkzeug ZUPT in Factory aufgenommen, den Entwicklungszweig der Distribution. Das Tool packt, komprimiert, prüft und verschlüsselt Archive in einem Schritt und bietet neben AES-256 ein hybrides Verfahren aus ML-KEM-768 und X25519. Für Admins ist das ein Hinweis auf eine neue Backup-Option auf SUSE-Systemen, aber noch kein Grund zur Eile.
Betroffen ist niemand zwingend: Es gibt keine Schwachstelle und keinen Patch. Wer Backups mit Borg, restic oder Veeam sichert, muss heute nichts ändern. Interessant ist die Meldung für Teams, die langlebige oder sensible Archive ablegen und das Risiko bewerten wollen, dass heute abgegriffene Daten später entschlüsselt werden. Ein Wartungsfenster ist nicht nötig, ein Testlauf in einer Laborumgebung genügt.
Was ist passiert?
Am 4. Oktober 2026 meldeten Phoronix und der openSUSE-Newsblog, dass ZUPT in openSUSE Factory akzeptiert wurde. Der Beitrag auf news.opensuse.org stammt von Alessandro de Oliveira Faria und ist als Community-Beitrag gekennzeichnet. Er nennt ZUPT eine „officially integrated solution“ für Backup, Kompression, Integritätsprüfung und Verschlüsselung im openSUSE-Umfeld.
Die Projektdokumentation auf GitHub beschreibt ZUPT als Kommandozeilen-Archivierer in C11 mit mehrfädiger Verarbeitung, eigenem Kompressionscodec, Integritätsprüfung und einer grafischen Oberfläche auf Python- und Qt-Basis. Der Quellcode-Stand im Repository ist Version 5.2.10 vom 1. Oktober 2026. Im Factory-Quellpaket liegt laut Build-Service-Schnittstelle am 5. Oktober 2026 dagegen Version 5.2.9 (Stand der Prüfung). Die zugehörige Paketänderung trägt das Datum 17. September 2026.
Für wen ist das relevant?
- Admins von openSUSE Tumbleweed und Leap, die ein schlankes Archivierungswerkzeug mit eingebauter Verschlüsselung suchen.
- Betreiber von Archiven mit langer Aufbewahrungsfrist, bei denen das Szenario „harvest now, decrypt later“ in der Risikoanalyse auftaucht.
- Nicht relevant: Umgebungen mit etablierter Backup-Software, Support-Verträgen und Compliance-Vorgaben, die ein bestimmtes Produkt verlangen.
Technische Eckdaten laut Projekt
Die Datei SECURITY.md im Repository nennt vier Modi. Ohne Verschlüsselung schützen nur Prüfsummen. Der Passwortmodus nutzt PBKDF2-SHA256 mit 600.000 Iterationen. Der Schalter --pq aktiviert das hybride Verfahren aus ML-KEM-768 und X25519 mit SHA3-512 als Kombinierer, --pq-only verwendet nur ML-KEM-768. Die Nutzdaten schützt in allen verschlüsselten Modi AES-256-CTR mit HMAC-SHA256. Das Projekt empfiehlt den Hybridmodus, sofern keine Richtlinie die klassische Komponente verbietet.
Typische Aufrufe laut INSTALL.md sind zupt compress, zupt test und zupt extract. Passwörter sollten per --password-prompt, --pass-file oder --pass-fd übergeben werden, weil die Option -p Passwörter in Prozessliste und Shell-Verlauf sichtbar machen kann.
Wie kritisch ist das?
Operativ unkritisch, aber mit Vorbehalten, die in der Berichterstattung fehlen. Das Projekt schreibt in SECURITY.md selbst, dass es kein unabhängiges Sicherheitsaudit und keine Zertifizierung gibt. Das README bezeichnet die Auslieferung von 5.2.10 als Vorabversion mit bekannten Problemen, weil ein strenger GCC-Test weiterhin fehlschlägt. Das Repository wurde im März 2026 angelegt und hatte bei der Prüfung 20 Sterne, die Gemeinschaft dahinter ist also klein.
Unklar ist außerdem die Lizenz im Paket. Upstream nennt AGPL-3.0-or-later für die Anwendung und GPL-3.0-or-later für den Codec. Die Spec-Datei im Factory-Quellpaket trägt dagegen „MIT“. Welche Angabe am Ende im Paket steht, ist unbestätigt. Das README beansprucht eine Aufnahme in Factory ausdrücklich nicht, es entstand also vor der Ankündigung. Die Build-Service-Schnittstelle zeigt für das Factory-Paket Revision 1 mit Zeitstempel 30. September 2026, die Ankündigung folgte am 4. Oktober.
Was sollten Admins jetzt tun?
- Inventar prüfen: Welche Systeme sichern wo und womit, und gibt es Archive, die über viele Jahre lesbar bleiben müssen?
- Auf einer Testmaschine mit Tumbleweed
zypper info zuptausführen und Version, Lizenzangabe und Repository vergleichen, bevor etwas installiert wird. - Archiv anlegen, mit
zupt testprüfen und auf einem zweiten System vollständig wiederherstellen. Ein Backup zählt erst nach erfolgreichem Restore. - Schlüssel und Passwörter getrennt vom Archiv aufbewahren und den Zugriff dokumentieren.
- Produktive Daten vorerst nicht ausschließlich mit ZUPT sichern, solange kein unabhängiges Audit vorliegt. Bestehende Backups parallel weiterlaufen lassen.
- Versionsstand beobachten: Factory zeigt 5.2.9, das Repository 5.2.10.
Einordnung für Unternehmen
Dass ein Distributionsprojekt post-quantensichere Verfahren in ein Backup-Werkzeug bringt, passt zur aktuellen Debatte um Migrationsfristen für Kryptografie. Für kleine und mittlere Unternehmen bleibt die Faustregel: Verschlüsselung ist nur so gut wie das Schlüsselmanagement, und ein neues, wenig erprobtes Werkzeug ersetzt keine geprüfte Backup-Strategie. Eine Aufnahme in Factory bedeutet außerdem noch keine Freigabe für stabile Veröffentlichungen. ZUPT eignet sich derzeit für Evaluierung und Zusatzarchive, nicht für den alleinigen Schutz geschäftskritischer Daten.
Diese Einordnung beruht ausschließlich auf Projekt- und Distributionsquellen. Ein eigener Praxistest der Software ist nicht Teil dieser Meldung.
Passende Anleitungen auf S-EDV
- Trump-Order setzt 2030-Frist für Post-Quanten-Krypto-Migration: Hintergrund zur Debatte um Migrationsfristen.
- restic-Backups unter Linux und Windows automatisieren: etablierte Alternative mit Verschlüsselung und Zeitplan.
- borgmatic im Docker-Container für automatische Server-Backups: Vergleichsansatz mit Borg.
