Darknight Coffee Netzwerk

Carrabelloy ' Meine Hobbys sind so vielseitig

Politik & Persönliches

Open Source & KI

Schlagwort: open-source

  • Mecklenburg-Vorpommern setzt auf Nextcloud: Digitale Souveränität beginnt nach der Pressemitteilung

    Podcastfolge: Nextcloud statt SharePoint – Mecklenburg-Vorpommerns Souveränitätstest

    Mecklenburg-Vorpommern macht etwas, das in der deutschen Digitalpolitik noch immer ungewöhnlich genug ist, um Aufmerksamkeit zu verdienen: Das Land ersetzt Microsoft SharePoint durch eine selbst kontrollierte Kollaborationsplattform auf Basis von Nextcloud. Rund 5.000 Beschäftigte nutzen das Filesharing bereits. Mittelfristig sollen Chat, Videokonferenzen und Groupware hinzukommen und mehr als 50.000 Beschäftigte in Landes- und Kommunalverwaltungen erreichen.

    Das ist keine bloße Absichtserklärung. Es gibt einen landeseigenen Betreiber, eine laufende Plattform und eine konkrete Migration. Trotzdem wäre es verfrüht, bereits den Sieg der digitalen Souveränität auszurufen. Open Source ist eine notwendige Grundlage. Souverän wird eine Verwaltung aber erst, wenn sie Betrieb, Wissen, Daten, Schlüssel, Wiederherstellung und Wechselpfad tatsächlich beherrscht.

    Mehr Substanz als die übliche Sonntagsrede

    Nach Angaben des Finanz- und Digitalisierungsministeriums betreibt die landeseigene DVZ M-V GmbH die Plattform. Nextcloud steht unter der GNU AGPLv3. Das Land nennt eigene Test- und Produktivumgebungen, Betriebsschulungen, Sicherheitsprüfungen und eine priorisierte Einbindung von Stabilitätsupdates. Der Umstieg von SharePoint sei schrittweise und ohne Datenverluste abgeschlossen worden.

    Diese Punkte sind wichtig. Ein benannter Betreiber ist besser als eine Wolke aus Unterauftragnehmern. Eine getrennte Testumgebung ist besser als Updates direkt im Produktivsystem. Eine laufende Migration ist mehr wert als die hundertste Strategie mit buntem Titelbild.

    Auch der politische Kontext stimmt: Mecklenburg-Vorpommern kooperiert seit 2025 mit Schleswig-Holstein. Parallel nennt das Land OpenProject und den auf OpenWebUI beruhenden Verwaltungschatbot LEA. Daraus könnte mehr als eine einzelne Nextcloud-Installation entstehen: ein offener Verwaltungsarbeitsplatz, dessen Bausteine nicht von einem einzigen US-Konzern diktiert werden.

    Open Source ist noch keine Souveränität

    Der Quellcode einer Software kann offen sein, während der reale Betrieb weiterhin abhängig bleibt. Wer administriert die Systeme? Wer hält die Verschlüsselungsschlüssel? Welche Komponenten stecken vor und hinter Nextcloud? Ist das Office-Paket offen? Läuft die Videokonferenz über eigene Infrastruktur? Sind Identitätsmanagement, Push-Dienste, Monitoring und Support austauschbar?

    Eine Verwaltung kann Nextcloud nutzen und trotzdem in einem neuen Lock-in landen: bei einem Integrator, bei proprietären Erweiterungen oder bei einem Sonderstand, den außer dem bisherigen Dienstleister niemand versteht. Deshalb muss das Land nicht nur Dateien exportieren können. Es braucht Dokumentation, Automatisierung, Versionsstände, Konfigurationen und ausreichend eigenes Personal, damit ein anderer Betreiber übernehmen könnte.

    Ein Matrix-Raum ist auch nicht souverän, nur weil Synapse Open Source ist. Ohne Signing Keys, Datenbank, Medien, Reverse-Proxy-Konfiguration und korrekte .well-known-Einträge lässt er sich nicht sauber wiederherstellen. Ebenso ist eine Nextcloud-Sicherung unvollständig, wenn nur Nutzdateien kopiert werden, aber Datenbank, Apps, Konfiguration, Secrets und Cronjobs fehlen.

    Der Restore ist die Stunde der Wahrheit

    Politik spricht gern über Clouds, Plattformen und Innovation. Seltener spricht sie über den langweiligen Teil, an dem sich Kontrolle entscheidet: Backups und Wiederherstellung.

    Ein Backup ist keine Erfolgsmeldung. Erst ein getesteter Restore beweist, dass Daten, Abhängigkeiten und Betriebswissen zusammenpassen. Für Mecklenburg-Vorpommern wären deshalb belastbare Antworten nötig: Gibt es getrennte, versionierte Sicherungen? Werden sie regelmäßig in einer isolierten Umgebung zurückgespielt? Wie lange dauert ein Wiederanlauf? Können zentrale Dienste bei einem Ausfall des Rechenzentrums weiterarbeiten? Wer entscheidet im Notfall über Schlüssel und DNS?

    Dass das Land in seiner Kooperation mit Schleswig-Holstein auch Resilienz und Desaster Recovery nennt, ist richtig. Entscheidend ist, ob daraus überprüfbare Praxis entsteht. Ein Dokument im Notfallhandbuch startet noch keinen Server.

    5.000 Nutzer sind ein Anfang – 50.000 eine andere Liga

    Filesharing für 5.000 Beschäftigte und eine vollständige Kollaborationsumgebung für mehr als 50.000 Menschen sind zwei verschiedene Aufgaben. Sobald Chat, Videokonferenzen, Kalender, Kontakte und gemeinsames Office hinzukommen, steigen Last, Supportbedarf und organisatorische Abhängigkeit.

    Dann zählen nicht nur CPU und Speicher. Es geht um Identitäten, Rollen, Barrierefreiheit, mobile Geräte, Aufbewahrungsregeln, Datenschutz, Schulung und Hilfe im Arbeitsalltag. Kommunen haben andere Voraussetzungen als Ministerien. Kleine Verwaltungen benötigen möglicherweise mehr Unterstützung, dürfen aber nicht zu bloßen Mandanten ohne Mitspracherecht werden.

    Die Zielzahl muss deshalb an aktiven Nutzern, tatsächlicher Funktionsnutzung, Verfügbarkeit und Zufriedenheit gemessen werden. Ein freigeschaltetes Konto ist noch kein gelungener Rollout.

    Die ökonomische Frage: Wer bekommt das Geld und wer behält das Wissen?

    Digitale Souveränität ist auch Industriepolitik. Öffentliche Milliarden können entweder Lizenzrenten und Abhängigkeiten finanzieren oder offene Infrastruktur, europäische Anbieter und dauerhaftes Wissen in der Verwaltung stärken.

    Das bedeutet nicht, dass Open Source kostenlos ist. Im Gegenteil: Betrieb, Integration, Sicherheit, Schulung und Weiterentwicklung müssen anständig bezahlt werden. Der Unterschied liegt darin, was nach der Zahlung übrig bleibt. Bei einem proprietären Vertrag bleiben häufig Nutzungsrechte und Abhängigkeit. Bei einer klugen Open-Source-Beschaffung bleiben zusätzlich Quellcode, Dokumentation, Standards, Wechselmöglichkeiten und idealerweise Verbesserungen für alle.

    Darum sollte Mecklenburg-Vorpommern offenlegen, welche Kosten die Migration und der laufende Betrieb verursachen, welche externen Dienstleister beteiligt sind und welche Anpassungen an die jeweiligen Projekte zurückgegeben werden. Öffentliche Mittel sollten keine unsichtbaren Sonderlösungen produzieren, sondern gemeinschaftlich nutzbare Infrastruktur.

    Kooperation statt 16 Landesinseln

    Die Zusammenarbeit mit Schleswig-Holstein ist möglicherweise der politisch stärkste Teil des Projekts. Deutschland braucht nicht 16 inkompatible Landesclouds und 11.000 kommunale Einzelwege. Es braucht gemeinsame offene Standards, wiederverwendbare Betriebsmodelle und föderale Strukturen, bei denen ein Land nicht vom guten Willen des anderen abhängig wird.

    Gemeinsam heißt dabei nicht zentralistisch. Mecklenburg-Vorpommern muss seine Daten und Entscheidungen selbst kontrollieren können. Gleichzeitig sollten Schnittstellen, Automatisierung, Sicherheitswissen und Beschaffungsunterlagen geteilt werden. So entsteht Redundanz: Wenn ein Betreiber ausfällt oder ein Vertrag endet, existiert ein realer Wechselpfad.

    Ein guter Anfang, der öffentlich geprüft werden muss

    Mecklenburg-Vorpommern verdient Anerkennung dafür, SharePoint nicht nur zu kritisieren, sondern praktisch zu ersetzen. Doch politische Glaubwürdigkeit entsteht nicht durch das Etikett „souverän“. Sie entsteht durch überprüfbare Kontrolle.

    In den kommenden Monaten sind deshalb konkrete Nachweise wichtiger als weitere Hochglanzmeldungen:

    • Wie entwickeln sich aktive Nutzerzahlen und kommunaler Rollout?
    • Welche Komponenten werden für Talk, Office und Groupware eingesetzt?
    • Wo liegen Daten, Schlüssel und Backups?
    • Gibt es dokumentierte und getestete Wiederherstellungen?
    • Können Betreiber und Dienstleister gewechselt werden?
    • Welche Kosten entstehen und welche Verbesserungen fließen upstream?
    • Gibt es unabhängige Sicherheitsprüfungen und veröffentlichbare Ergebnisse?

    Wenn diese Fragen sauber beantwortet werden, kann aus dem Projekt ein Vorbild werden. Wenn nicht, bleibt Nextcloud nur ein anderes Logo auf einer weiterhin fremdbestimmten Infrastruktur.

    Digitale Souveränität bedeutet nicht, dass der Staat alles selbst programmieren muss. Sie bedeutet, dass er jederzeit verstehen, prüfen, betreiben, wiederherstellen und wechseln kann. Mecklenburg-Vorpommern hat einen ernst zu nehmenden Anfang gemacht. Jetzt beginnt der Teil, an dem sich entscheidet, ob aus Software tatsächlich politische Handlungsfähigkeit wird.

    Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

    Quellen

    1. Ministerium für Finanzen und Digitalisierung Mecklenburg-Vorpommern, „Auf dem Weg zur Digitalen Souveränität: Mecklenburg-Vorpommern setzt auf Open Source“, 3. Juli 2026: https://www.regierung-mv.de/Landesregierung/fm/Aktuell/?id=221531
    2. DVZ M-V GmbH, „Mecklenburg-Vorpommern setzt auf Open Source“, 3. Juli 2026: https://www.dvz-mv.de/news/mecklenburg-vorpommern-setzt-auf-open-source
    3. Gemeinsame Kooperation Mecklenburg-Vorpommern/Schleswig-Holstein zur digitalen Souveränität, 21. Oktober 2025: https://www.regierung-mv.de/Aktuell/?id=215184
  • Der Geheimdienst als Hacker: Mehr Cybermacht verlangt stärkere Kontrolle

    Der Geheimdienst als Hacker: Mehr Cybermacht verlangt stärkere Kontrolle

    Ein kompromittierter Community-Server taucht in der Spur eines Cyberangriffs auf. Die IP-Adresse passt, der Datenverkehr lief über Nginx, vielleicht wurde sogar ein gültiger gestohlener Token benutzt. Nur der Betreiber des Servers war nicht der Angreifer. Sein System war eine Zwischenstation.

    Was geschieht, wenn ein Nachrichtendienst auf diese Spur nicht nur mit Beobachtung reagiert, sondern aktiv in das vermeintliche Angriffssystem eingreift? Wer prüft die Attribution? Wer stoppt die Maßnahme, wenn auf dem Host außerdem Matrix-Räume, Websites und Backups Unbeteiligter liegen? Und wer erfährt später, was der Staat getan hat?

    Diese Fragen sind nicht theoretisch. Das Bundesinnenministerium hat Anfang Juli 2026 einen rund 700 Seiten umfassenden Referentenentwurf zur Reform des Nachrichtendienstrechts veröffentlicht. Nach den ausgewerteten Quellen sollen BND und Verfassungsschutz unter bestimmten Voraussetzungen fremde IT-Systeme manipulieren, Datenströme umleiten und den Betrieb von Systemen einschränken oder unterbinden dürfen. Der Entwurf verbindet diese operativen Befugnisse mit automatisierter Datenanalyse, biometrischen Abgleichen und Zugriffen auf Videoüberwachung. [1][10][11][12]

    Die erste notwendige Einordnung: Das Vorhaben ist ein Referentenentwurf, kein geltendes Gesetz. Im weiteren Verfahren kann der Text noch verändert werden. Auch die scharfe Kritik aus Datenschutzaufsicht, Freiheitsrechtsorganisationen, IT-Sicherheitscommunity, Anwaltschaft und Medien ist eine fachliche Bewertung, keine rechtskräftige Feststellung der Verfassungswidrigkeit. [4][5][7][8][9]

    Trotzdem ist die politische Schwelle klar. Deutschland diskutiert nicht nur mehr Überwachung. Es diskutiert den Umbau von Nachrichtendiensten zu operativen Cyberakteuren.

    Die Regierung hat ein reales Problem

    Die Bundesregierung begründet die Reform mit einer verschärften Bedrohungslage, Spionage, Sabotage und schweren Cyberangriffen. Sie will nationale Souveränität und operative Fähigkeiten stärken, den Datenaustausch zwischen Behörden verbessern und das Nachrichtendienstrecht an Entscheidungen des Bundesverfassungsgerichts anpassen. [2][3][10]

    Diese Gegenposition darf nicht unterschlagen werden. Ein Staat schützt seine Infrastruktur nicht ausreichend, wenn er einen laufenden Angriff nur dokumentiert. Bei akuter Gefahr kann eine zusätzliche Freigabestufe Zeit kosten. Auch die geplante Bündelung der Aufsicht beim Unabhängigen Kontrollrat könnte Zuständigkeiten klären und Doppelarbeit vermeiden.

    Doch eine reale Bedrohung beantwortet noch nicht, welche Eingriffe angemessen sind. Zwischen dem Isolieren eines eigenen Systems und dem Manipulieren eines fremden Servers liegt eine grundlegende Grenze. Wer die eigene Nginx-Instanz vom Netz trennt, einen Synapse-Admin-Token widerruft oder einen kompromittierten Matrix-Raum sperrt, handelt in der eigenen Infrastruktur. Wer Daten auf einem fremden Rechner löscht oder dessen Betrieb stört, kennt weder alle Nutzer noch alle Nebenwirkungen.

    Bewertung: Der Staat braucht wirksame Cyberabwehr. Aber operative Nachrichtendienstbefugnisse dürfen nicht mit dem allgemeinen Hinweis auf eine gefährliche Welt begründet werden. Je schwerer der Eingriff, desto konkreter müssen Schwelle, Zielprüfung, Abbruchmöglichkeit und Verantwortlichkeit geregelt sein.

    Eine IP-Adresse ist kein Täter

    Cyberangriffe laufen über Botnetze, gekaperte Router, kompromittierte Server, fremde Cloud-Konten und VPNs. Ein Nginx-Log kann belegen, von welcher Adresse eine Anfrage kam. Ein Token kann belegen, welcher Zugang benutzt wurde. Beides beweist nicht automatisch, welcher Mensch den Angriff gesteuert hat.

    Das ist beim Hackback zentral. Trifft eine operative Maßnahme eine missbrauchte Zwischenstation, kann sie genau den Server beschädigen, dessen Betreiber selbst Opfer des Angriffs ist. Auf gemeinsam genutzter Infrastruktur können gleichzeitig unbeteiligte Websites, Datenbanken, Matrix-Räume und Backups liegen.

    Besonders problematisch ist deshalb eine Passage, nach der automatisierte Systeme operative Maßnahmen auslösen können sollen. Netzpolitik.org zitiert die Entwurfsbegründung: „Ein Zwischenschritt menschlicher Bearbeitung leistet hier keine relevante Qualitätssicherung, verzögert aber Abwehr erfolgsgefährdend.“ Nach der ausgewerteten Fassung können damit auch automatisiert ausgelöste Hackbacks gemeint sein. [10][11]

    Automatisierung verkürzt Reaktionszeiten. Sie beseitigt aber keine manipulierten, lückenhaften oder mehrdeutigen Daten. Ein Angreifer kann fremde Infrastruktur gerade deshalb nutzen, um die technische Spur von sich wegzuführen. Ein schneller falscher Eingriff bleibt ein falscher Eingriff.

    Die Bundesdatenschutzbeauftragte sieht bei automatisierten operativen Interventionen erhebliche verfassungsrechtliche Risiken. Rechtsanwalt Peter Schantz hält es für unverantwortlich, die Attribution eines Cyberangriffs einem autonomen System zu überlassen. Diese Stellungnahmen sind keine Gerichtsurteile. Sie benennen aber das ungelöste Kernproblem. [4][6]

    Bewertung: Eine menschliche Freigabe garantiert keine richtige Entscheidung. Doch bei Eingriffen in fremde Systeme muss eine verantwortliche Person identifizierbar bleiben. Ein Modell darf unterstützen und priorisieren. Es darf Verantwortung nicht in einem undurchsichtigen Prozess verschwinden lassen.

    Zero Days: Schützen oder ausnutzen

    Nach der Entwurfsdarstellung soll das Bundesamt für Sicherheit in der Informationstechnik auch Informationen über Software-Schwachstellen und Zero Days an den BND weitergeben. Die AG KRITIS warnt, dies könne das Vertrauen in das BSI und die Widerstandsfähigkeit kritischer Infrastruktur schwächen. [7][10][11]

    Der Konflikt ist einfach zu beschreiben und schwer zu lösen. Eine unbekannte Schwachstelle kann koordiniert an Hersteller und Open-Source-Projekte gemeldet werden, damit ein Patch entsteht. Oder sie kann geheim bleiben, um sie offensiv gegen ein Ziel einzusetzen. Solange sie zurückgehalten wird, bleiben jedoch alle betroffenen Systeme verwundbar.

    Eine Lücke in einer verbreiteten Linux-, Nginx- oder Matrix-Komponente betrifft nicht nur ein außenpolitisches Ziel. Sie kann auf Servern von Kommunen, Unternehmen, Vereinen und privaten Betreibern vorhanden sein. Auch ein sauberes Backup löst dieses Problem nicht. Ein Restore stellt Daten wieder her; er schließt keine unbekannte Lücke.

    Darum braucht der Staat ein überprüfbares Schwachstellenverfahren:

    • Schutz und koordinierte Offenlegung müssen der Regelfall sein.
    • Eine Zurückhaltung braucht eng definierte Voraussetzungen.
    • Das Risiko für unbeteiligte Betreiber muss unabhängig bewertet werden.
    • Jede Entscheidung braucht eine kurze Frist und regelmäßige Neubewertung.
    • Betroffene Projekte müssen nach der Freigabe sicher und koordiniert informiert werden.

    Bewertung: Das BSI kann nur glaubwürdig für Sicherheit werben, wenn Betreiber darauf vertrauen dürfen, dass gemeldete Schwachstellen vorrangig geschlossen werden. Offensive Interessen dürfen diesen Schutzauftrag nicht still überstimmen.

    Wenn Datenanalyse in operative Macht übergeht

    Der Referentenentwurf soll automatisierte Auswertungen personenbezogener Daten erlauben. Dazu zählen ausdrücklich selbstlernende und auf autonomen Betrieb ausgelegte Systeme. Hinzu kommen biometrische Abgleiche, Zugriffe auf private und öffentliche Videoüberwachung und die Möglichkeit, eine laufende BND-Überwachung nach Einreise einer Zielperson bis zu 72 Stunden im Inland fortzusetzen. [10][11][12]

    Jede dieser Maßnahmen hat eigene Voraussetzungen. In der Kombination entsteht jedoch eine neue Qualität. Daten aus verschiedenen Quellen können Bewegungen, Kontakte und vermeintliche Beziehungen sichtbar machen. Sie können aber auch falsche Gewissheit produzieren: ein gemeinsamer Ort, ein geteiltes Gerät, ein ähnliches Gesicht oder eine technisch vermittelte Verbindung wird zur verdächtigen Nähe.

    Die Bundesdatenschutzbeauftragte warnt vor „rechtswidrigen additiven Grundrechtseingriffen“ und einem „erheblichen Überwachungsdruck für die Gesellschaft“. Der Deutsche Anwaltverein sieht das Mandatsgeheimnis gefährdet. Medienorganisationen kritisieren unzureichenden Quellenschutz. Die Bundesnotarkammer fordert stärkeren Schutz notarieller Verschwiegenheit. [4][8][9][12]

    Damit geht es nicht nur um Technik. Vertrauliche Beziehungen zwischen Anwalt und Mandant, Journalist und Quelle oder Notar und Klient sind Infrastruktur des Rechtsstaats. Werden ihre Datenbestände automatisiert verbunden, reicht eine spätere Löschung nicht als Schutz.

    Bewertung: Mehr Daten schaffen nicht automatisch mehr Wahrheit. Der Gesetzgeber muss festlegen, welche Daten überhaupt zusammengeführt werden dürfen, welche besonders geschützten Bereiche technisch ausgeschlossen werden und wie Fehlzuordnungen erkannt werden. „Die Maschine hat es so bewertet“ darf niemals eine Begründung für einen schweren Eingriff sein.

    Kontrolle muss technisch auf Augenhöhe sein

    Der Entwurf will die Aufsicht über BND und Verfassungsschutz beim Unabhängigen Kontrollrat bündeln. Das kann sinnvoll sein. Eine Bündelung ist aber noch keine Stärkung.

    Nach den ausgewerteten Stellungnahmen soll die Bundesdatenschutzbeauftragte bei der Kontrolle operativer Tätigkeiten künftig nicht dieselbe Rolle haben. Kritisiert wird außerdem, dass die erste öffentliche Berichtsperiode des Unabhängigen Kontrollrats die Jahre 2028 bis 2030 umfassen und der Bericht erst 2031 erscheinen könnte. Berichte sollen nach Darstellung der BfDI ganz oder teilweise untersagt werden können. Für bestimmte Maßnahmen, etwa Zugriffe auf Videoanlagen, werden fehlende Vorabkontrollen beanstandet. [4][10]

    Kontrolle ist mehr als eine Behörde im Organigramm. Wer KI-Analyse, Schadsoftware und Hackbacks kontrolliert, muss Datenflüsse, Modelltests, Zielauswahl, Schwellenwerte, Freigaben und Nebenwirkungen nachvollziehen können. Prüfer brauchen Zugriff auf vollständige, manipulationsgeschützte Logs. Sie müssen erkennen können, ob ein Angriff tatsächlich vom getroffenen System ausging oder ob der Staat eine Zwischenstation erwischt hat.

    Der Unterschied lässt sich aus dem Serverbetrieb erklären. Ein Betreiber kann behaupten, täglich Backups zu erstellen. Erst ein Restore-Test zeigt, ob Datenbank, Medien, Schlüssel und Konfiguration vollständig sind. Genauso reicht bei einem Geheimdienst nicht die Behauptung, eine Maßnahme sei rechtmäßig kontrolliert worden. Es braucht überprüfbare Nachweise.

    Ein erster öffentlicher Bericht im Jahr 2031 wäre für einen tiefen Umbau im Jahr 2026 politisch zu spät. Bis dahin können sich fehlerhafte Routinen und institutionelle Interessen verfestigt haben.

    Bewertung: Der Unabhängige Kontrollrat braucht genügend Personal, eigene technische Fachleute, Zugriff auf Werkzeuge und Einsatzprotokolle, Vorabkontrolle bei schweren Maßnahmen, Abbruchrechte und zeitnahe Berichtspflichten. Kontrolle ohne reale Prüfdichte ist Dekoration.

    Fünf Prüfsteine für das Gesetzgebungsverfahren

    Erstens muss Attribution nachvollziehbar sein. Eine IP-Adresse, ein Logeintrag oder ein Token dürfen nicht allein zum Zielentscheid führen. Alternative Erklärungen und die Gefahr einer kompromittierten Zwischenstation müssen dokumentiert geprüft werden.

    Zweitens muss das Schließen von Schwachstellen Vorrang haben. Jede offensive Zurückhaltung braucht enge Kriterien, Befristung und unabhängige Neubewertung.

    Drittens muss menschliche Verantwortung sichtbar bleiben. Automatisierte Systeme können unterstützen, dürfen aber bei Eingriffen in fremde Systeme keine verantwortungsfreie Zone schaffen.

    Viertens muss Aufsicht technisch gleichwertig wachsen. Neue Befugnisse ohne Personal, Prüfrechte, vollständige Logs und Eingriffsmöglichkeiten der Kontrolleure sind ein Sicherheitsrisiko.

    Fünftens braucht es zeitnahe öffentliche Rechenschaft. Geheimhaltung kann operative Details schützen. Sie darf nicht verhindern, dass Parlament und Öffentlichkeit erfahren, wie oft Befugnisse genutzt wurden, wie viele Fehlzuordnungen auftraten und welche Schäden entstanden.

    Fazit: Der Rechtsstaat braucht mehr als schnelle Systeme

    Die Regierung benennt reale Gefahren. Spionage, Sabotage und Cyberangriffe verlangen handlungsfähige Institutionen. Das rechtfertigt eine Reformdebatte. Es rechtfertigt keinen Blankoscheck.

    Meine klare Bewertung: Der Referentenentwurf darf nicht durchgewunken werden. Wer Nachrichtendiensten Hackbacks, Zero-Day-Nutzung und automatisiert ausgelöste Maßnahmen ermöglicht, schafft zusätzliche Risiken für gemeinsam genutzte Infrastruktur und unbeteiligte Betreiber. Diese Macht muss enger begrenzt, technisch kontrolliert und schneller öffentlich bilanziert werden.

    Der Rechtsstaat beweist sich nicht daran, dass er technisch alles kann. Er beweist sich daran, dass Eingriffe begründet, begrenzt und überprüft werden. Ein Geheimdienst, der selbst hacken darf, braucht deshalb nicht weniger Kontrolle, sondern technisch stärkere, schnellere und sichtbarere Kontrolle.

    Der parallele Streit um Einschränkungen des Informationsfreiheitsgesetzes bleibt in diesem Beitrag bewusst außen vor. Ein rechtlicher oder kausaler Zusammenhang mit der Geheimdienstreform ist bislang nicht belastbar belegt.

    Quellen

    1. Bundesministerium des Innern: Gesetz zur Reform des Nachrichtendienstrechts, Gesetzgebungsverfahren und Referentenentwurf, abgerufen am 25. Juli 2026: https://www.bmi.bund.de/SharedDocs/gesetzgebungsverfahren/DE/OESI2/nachrichtendienstrecht.html
    2. Deutscher Bundestag / Bundesregierung: Antwort auf die Kleine Anfrage „Parlamentarische Transparenz bei geplanten Befugniserweiterungen des Bundesnachrichtendienstes“, Bundestagsdrucksache 21/4302, 2026: https://dserver.bundestag.de/btd/21/043/2104302.pdf
    3. Deutscher Bundestag, hib 154/2026: Regierung will das BND-Gesetz systematisch reformieren, 3. März 2026: https://www.bundestag.de/presse/hib/kurzmeldungen-1151276
    4. Bundesbeauftragte für den Datenschutz und die Informationsfreiheit: Stellungnahme zur Reform des Nachrichtendienstrechts, 2026: https://www.bfdi.bund.de/SharedDocs/Downloads/DE/DokumenteBfDI/Stellungnahmen/2026/Stgn_Reform-Nachrichtendienst.pdf?__blob=publicationFile
    5. Gesellschaft für Freiheitsrechte: Stellungnahme zum Entwurf eines Gesetzes zur Reform des Nachrichtendienstrechts, 2026: https://freiheitsrechte.org/uploads/publications/Digital/GFF_Stellungnahme_Entwurf_Reform_Nachrichtendienstrecht.pdf
    6. Peter Schantz: Stellungnahme zum Entwurf des BND-Gesetzes, 2026: https://freiheitsrechte.org/uploads/publications/Digital/Stellungnahme_BND-Gesetz_2026_final.pdf
    7. AG KRITIS: Stellungnahme zum Referentenentwurf einer Reform des Nachrichtendienstrechts, 14. Juli 2026: https://ag.kritis.info/2026/07/14/stellungnahme-zum-referentenentwurf-einer-reform-des-nachrichtendienstrechts/
    8. Deutscher Anwaltverein: Nachrichtendienste: Mehr Befugnisse, weniger Kontrolle, Stellungnahme/Pressemitteilung 26/26, 2026: https://anwaltverein.de/newsroom/pm-26-26-nachrichtendienste-mehr-befugnisse-weniger-kontrolle
    9. ARD und weitere Medienorganisationen: Stellungnahme zum Nachrichtendienstrecht, 15. Juli 2026: https://www.ard.de/die-ard/organisation-der-ard/standpunkte/2026-07-15-nachrichtendienstrecht-100.pdf
    10. netzpolitik.org: Stellungnahmen zur Geheimdienstreform: „Ein erheblicher Überwachungsdruck für die Gesellschaft“, 24. Juli 2026: https://netzpolitik.org/2026/stellungnahmen-zur-geheimdienstreform-ein-erheblicher-ueberwachungsdruck-fuer-die-gesellschaft/
    11. netzpolitik.org: Geheimdienstreform: Zeitenwende für Spione, 10. Juli 2026: https://netzpolitik.org/2026/geheimdienstreform-zeitenwende-fuer-spione/
    12. Correctiv: Mehr Befugnisse, weniger Kontrolle: Verbände kritisieren geplante Reform der Nachrichtendienste, 17. Juli 2026, aktualisiert am 20. Juli 2026: https://correctiv.org/aktuelles/sicherheit-und-verteidigung/2026/07/17/mehr-befugnisse-weniger-kontrolle-breite-kritik-an-geplanter-reform-der-nachrichtendienste-bnd-bundesnachrichtendienst-bfv-verfassungsschutz-dobrindt/

    CTA

    Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

  • AGI ist da? Gegen den Hype, gegen die Blockade – für souveräne KI

    AGI ist da? Gegen den Hype, gegen die Blockade – für souveräne KI

    Wer heute behauptet, AGI sei da, muss zuerst erklären, was mit AGI gemeint ist. Geht es um breite Problemlösefähigkeit, um Leistungen auf menschlichem Niveau, um autonome Zielverfolgung oder schlicht um ein Modell, das in vielen Tests beeindruckt? Ohne diese Trennung wird aus einer technischen Debatte ein Glaubenskampf. Die einen verkaufen Produktreife, die anderen diskutieren Bewusstsein, und am Ende redet niemand über dieselbe Sache.

    Mein Gegenpool richtet sich deshalb gegen zwei bequeme Lager zugleich: gegen den Hype, der aus jeder starken Demonstration einen historischen Wendepunkt macht, und gegen die Blockade, die jede neue Fähigkeit reflexhaft als Täuschung oder Gefahr abtut. Beides nimmt uns die politische Gestaltung aus der Hand.

    Ein Benchmark ist kein Thron

    Die Studie „Levels of AGI“ schlägt vor, Fähigkeiten nach Leistungsniveau, Breite und Autonomie zu unterscheiden. Das ist brauchbarer als ein binäres Etikett. Ein System kann in einzelnen Bereichen übermenschlich sein und bei alltäglichen Aufgaben scheitern. Es kann Texte, Code oder Bilder erzeugen und dennoch keine belastbare Verantwortung für die Folgen übernehmen.

    Auch METRs Forschung zu langen Aufgabenhorizonten misst eine konkrete Fähigkeit unter definierten Bedingungen. Solche Messungen sind wichtig. Sie beweisen aber weder Bewusstsein noch allgemeine Verlässlichkeit und schon gar nicht, dass ein System in einer realen Organisation unbeaufsichtigt handeln sollte.

    Im Serveralltag ist der Unterschied leicht zu sehen. Ein Modell kann eine plausible Nginx-Konfiguration erzeugen. Ob sie zum vorhandenen TLS-Setup, zu Weiterleitungen und zu den tatsächlichen Diensten passt, zeigt erst der Test. Ebenso kann ein Assistent einen Synapse-Fehler erklären, aber einen falschen Homeserver, eine andere Paketversion oder einen unzutreffenden Installationsweg voraussetzen.

    Ein beeindruckendes Ergebnis verdient Anerkennung. Es verdient nicht automatisch Root-Rechte.

    Capability ist noch keine Verantwortung

    Starke Fähigkeiten schaffen keine Haftung. Zwischen Können und verantwortlichem Einsatz liegen Zuständigkeiten, minimale Rechte, Protokolle, Verifikation und ein Rückweg. Genau darauf zielt auch das NIST AI Risk Management Framework mit seinen Bereichen Govern, Map, Measure und Manage.

    Ein Agent mit Schreibzugriff auf eine WordPress-Instanz kann einen fertigen Artikel veröffentlichen. Daraus folgt nicht, dass er ohne eindeutige Freigabe veröffentlichen sollte. Ein Werkzeug mit Zugriff auf Matrix-Tokens kann Räume verwalten. Daraus folgt nicht, dass es alle Tokens sehen oder dauerhaft behalten muss.

    Der vernünftige Weg ist unspektakulär:

    • Aufgaben klar begrenzen;
    • nur notwendige Rechte vergeben;
    • Tokens trennen, befristen und widerrufbar halten;
    • Ergebnisse vor hoher Wirkung vollständig prüfen;
    • vor Änderungen Backup und Rollback festlegen;
    • öffentliche Aktionen an eine eindeutige Freigabe binden.

    Capability ohne Governance ist kein Fortschritt, sondern ein ungesicherter Beschleuniger.

    Drei Lager und ihre blinden Flecken

    Das Rendite-Lager will schnell skalieren und Kosten externalisieren. Es behandelt Beschäftigte, Daten, Energie und gesellschaftliche Risiken als nachgelagerte Probleme. Das Neugier-Lager erkennt reale Möglichkeiten, unterschätzt aber leicht, wie aus einem Experiment ein dauerhafter Prozess mit Zugängen, Abhängigkeiten und Haftungsfragen wird. Das Moralblock-Lager sieht berechtigte Gefahren, kann jedoch Entwicklung und eigenes Wissen so stark bremsen, dass am Ende wieder einige wenige Konzerne die Technik kontrollieren.

    Eine souveräne Position nimmt von allen drei Seiten etwas ernst: die Innovationskraft, die Notwendigkeit von Grenzen und die Frage, wer Kosten und Nutzen trägt. Sie verweigert sich aber ihren Absolutheiten.

    Für eine kleine Community bedeutet das: Automatisierung darf Arbeit erleichtern, aber sie darf das Betreiberwissen nicht auffressen. Wenn ein Assistent jede Konfiguration erzeugt und nur noch ein Senior blind bestätigt, lernt der Nachwuchs weder DNS noch TLS noch Logauswertung. Wenn Moderation vollständig an Klassifikatoren ausgelagert wird, verliert die Community die Fähigkeit, Regeln zu begründen und Konflikte selbst zu bearbeiten.

    Physical AI: Wenn ein Fehler Gewicht bekommt

    Bei Physical AI verlässt der Fehler den Bildschirm. Ein Haushaltsroboter, ein Pflegesystem oder eine autonome Maschine bewegt Masse durch reale Räume. Eine falsche Klassifikation kann dann nicht nur einen unpassenden Text erzeugen, sondern eine Person verletzen, Eigentum beschädigen oder sensible Situationen aufzeichnen.

    Damit verschmelzen Datenschutz, Produktsicherheit und Haftung. Ein System muss nicht bewusst sein, um gefährlich oder nützlich zu handeln. Die Bewusstseinsfrage ist philosophisch interessant; für den Betrieb sind Kräfte, Sensorgrenzen, Abschaltmöglichkeiten, Protokolle und Verantwortlichkeiten unmittelbarer.

    Zwei Prüfungen gehören deshalb zusammen. Technisch muss geklärt werden, welche Zustände, Geschwindigkeiten und Kräfte erlaubt sind und wie ein sicherer Stopp funktioniert. Sozial muss geklärt werden, wer Daten sehen darf, wer Entscheidungen überprüft und wer für Schäden einsteht.

    Sobald KI einen Körper bekommt, bekommt auch ihr Fehler Masse, Geschwindigkeit und Reichweite.

    Europa und Silicon Valley: Die falsche Wahl

    Europa wird gern vor eine falsche Alternative gestellt: entweder schnelles Silicon-Valley-Tempo oder Grundrechte und Regulierung. Tatsächlich braucht Europa beides – Entwicklungskraft und demokratische Kontrolle. Regeln ohne eigene Infrastruktur machen abhängig. Infrastruktur ohne Rechte reproduziert nur das Machtmodell anderer Anbieter unter europäischer Flagge.

    Der AI Act folgt einem risikobasierten Ansatz. Das ist sinnvoll, wenn Regeln nicht beim Papier enden. Kleine Betreiber und Open-Source-Projekte brauchen verständliche Anforderungen, zugängliche Prüfwerkzeuge und klare Abgrenzungen. Große Anbieter dürfen Regulierung nicht als Markteintrittsbarriere benutzen, die sie selbst mit Rechtsabteilungen überwinden, während kleinere Alternativen verschwinden.

    Digitale Souveränität entsteht außerdem nicht durch den Firmensitz allein. Entscheidend sind offene Standards, exportierbare Daten, dokumentierte Schnittstellen, kontrollierbare Schlüssel und eine realistische Wechselmöglichkeit. Ein europäisches Produkt mit geschlossenem Format kann unfreier sein als ein transparent betriebener offener Dienst.

    Öffentliche Beschaffung könnte hier Macht verschieben: nicht nur Funktionen einkaufen, sondern Portabilität, Reproduzierbarkeit, Sicherheitspflege und Exit-Fähigkeit verlangen. Wer öffentliche Infrastruktur liefert, muss erklären können, wie sie ohne ihn weiterbetrieben werden kann.

    Arbeit: Produktivität ist eine Verteilungsfrage

    Die Internationale Arbeitsorganisation unterscheidet bei generativer KI zwischen Exposition, Transformation und vollständiger Ersetzung. Diese Unterscheidung ist zentral. Ein Beruf besteht aus vielen Tätigkeiten. Einige lassen sich automatisieren, andere verändern sich, wieder andere gewinnen an Bedeutung.

    Der gesellschaftliche Ausgang ist nicht technisch vorbestimmt. Wenn Produktivität steigt, können Gewinne wachsen, mehr Leistungen produziert oder Arbeitszeiten verkürzt werden. Welche Mischung entsteht, ist eine Macht- und Verteilungsfrage.

    Frühere Automatisierungswellen haben neue Berufe geschaffen. Das ist kein Trost für Menschen, deren Einkommen heute wegfällt und denen morgen der Zugang zu Qualifizierung fehlt. Übergänge brauchen Zeit, soziale Sicherung und Mitbestimmung. Sonst werden Gewinne privatisiert und Anpassungskosten auf Beschäftigte und öffentliche Haushalte verschoben.

    Auch Bildung darf nicht auf Bedienkompetenz schrumpfen. Wer nur noch Prompts formuliert, ohne Quellen, Code, Logs oder Argumente beurteilen zu können, wird vom Werkzeug abhängig. Der bessere Lernpfad lautet: Vorschlag erklären lassen, im Testsystem ausführen, Ergebnis prüfen, Fehler begründen und erst dann übernehmen.

    Automatisierung verteilt nicht von selbst Wohlstand. Sie verteilt zuerst Macht.

    Sieben Leitlinien für souveräne KI

    Aus der abstrakten AGI-Debatte lässt sich ein konkreter Handlungsrahmen ableiten:

    1. Begriffe vor Behauptungen: Wer AGI sagt, benennt Breite, Leistungsniveau und Autonomie.
    2. Aufgaben statt Magie: Jeder Einsatz erhält klare Ein- und Ausgaben, Grenzen und Erfolgskriterien.
    3. Minimale Rechte: Kein Agent bekommt mehr Zugriff, als die konkrete Aufgabe verlangt.
    4. Verifikation: Quellen werden geöffnet, Konfigurationen getestet und risikoreiche Ergebnisse vollständig geprüft.
    5. Rückweg: Vor Änderungen existieren Sicherung, Rollback und eine verantwortliche Person.
    6. Offene Alternativen: Datenexport, offene Protokolle und dokumentierte Schnittstellen werden vor dem Lock-in geplant.
    7. Gegenpool: Zu großen Behauptungen gehört eine belastbare Gegenposition; Tatsache, Quelle, Analyse und Meinung bleiben getrennt.

    Diese Regeln verhindern weder Innovation noch Fehler. Sie machen Entscheidungen sichtbar und korrigierbar. Souveränität ist kein Alles-oder-nichts-Zustand. Sie wächst durch eigene Domains, getrennte Konten, kontrollierte Schlüssel, exportierbare Daten, dokumentierte Konfigurationen und getestete Backups.

    Vielleicht werden wir später sagen, eine Form kompetenter AGI sei 2025 oder 2026 bereits vorhanden gewesen. Vielleicht werden wir feststellen, dass das Schlagwort mehr verdeckt als erklärt hat. Für die heutige Praxis ist entscheidend: Wir haben leistungsfähige, fehlerhafte Systeme, die Arbeit, Infrastruktur und Macht verändern.

    Wir brauchen deshalb keine neue Religion – weder eine des Heils noch eine des Untergangs. Wir brauchen Betreiberwissen, demokratische Regeln, freie Alternativen und den Mut, einer beeindruckenden Maschine nicht blind die Schlüssel zu geben.

    Quellen

    1. Meredith Ringel Morris et al., „Levels of AGI: Operationalizing Progress on the Path to AGI“:
      https://arxiv.org/abs/2311.02462
    2. METR, „Measuring AI Ability to Complete Long Tasks“:
      https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/
    3. NIST, „Artificial Intelligence Risk Management Framework“:
      https://www.nist.gov/itl/ai-risk-management-framework
    4. Europäische Kommission, „Regulatory framework for AI“:
      https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
    5. Internationale Arbeitsorganisation, „Generative AI and Jobs: A Refined Global Index of Occupational Exposure“:
      https://www.ilo.org/publications/generative-ai-and-jobs-refined-global-index-occupational-exposure

    CTA

    Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
    Podcast: https://podcast.darknight-coffee.org/pages/startseite
    Blog: https://carrabelloy.darknight-coffee.org/blog/
    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

  • Das Fediverse patcht sich nicht selbst: Souveränität braucht ein Wartungsfenster

    Das Fediverse patcht sich nicht selbst: Souveränität braucht ein Wartungsfenster

    Ein eigener Mastodon-Server ist ein starkes Stück digitaler Handlungsfähigkeit. Die Domain bleibt unter eigener Kontrolle, Regeln können in der Community entstehen, und ein Plattformkonzern kann den Kommunikationsraum nicht per Geschäftsentscheidung abschalten. Doch dann kommt die Sicherheitsmeldung: Mastodon aktualisieren, FFmpeg prüfen, Backup anlegen.

    Genau hier endet die romantische Erzählung und beginnt digitale Souveränität in der Praxis. Freiheit besteht nicht nur darin, Software installieren zu dürfen. Sie besteht darin, Abhängigkeiten zu erkennen, einen sicheren Patchpfad zu wählen, einen Rückweg vorzubereiten und nach dem Neustart den vollständigen Dienst zu prüfen.

    Der aktuelle Anlass: Drei Patchstände und eine Frist

    Das Mastodon-Projekt hat am 17. Juli 2026 die Versionen 4.6.3, 4.5.13 und 4.4.20 als aktuelle Stände der unterstützten Zweige genannt und allen Administratoren ein Update empfohlen. Gleichzeitig endet die Unterstützung für Mastodon 4.4 am 17. Dezember 2026. Versionen vor 4.4 sind laut Sicherheitsrichtlinie bereits nicht mehr unterstützt.

    Damit entstehen zwei Aufgaben, die nicht vermischt werden dürfen. Wer in einem unterstützten Zweig arbeitet, muss kurzfristig den korrekten Patchstand erreichen. Wer noch Mastodon 4.4 betreibt, braucht zusätzlich einen geplanten Weg auf einen neueren Zweig, bevor die Sicherheitsunterstützung endet.

    Das ist mehr als Versionspflege. Die dokumentierten Mindestanforderungen steigen zwischen 4.4 und 4.6: Ruby von 3.2 auf 3.3, PostgreSQL von 13 auf 14, Redis von 6.2 auf 7 und Node von 20 auf 22. Diese Tabelle sagt nicht, dass jedes System alle Komponenten gleichzeitig austauschen muss. Sie zeigt aber, warum ein Minor-Upgrade kein blindes Ersetzen eines Mastodon-Pakets ist.

    Die Lücke sitzt in FFmpeg, nicht in der Timeline

    Teil der Sicherheitslage ist CVE-2026-8461. Nach dem Datensatz der National Vulnerability Database betrifft die Schwachstelle den MagicYUV-Decoder in FFmpegs libavcodec. Beschrieben ist ein Out-of-bounds-Write, der einen Denial-of-Service und unter bestimmten Bedingungen die Ausführung fremden Codes ermöglichen kann.

    Zur belastbaren Einordnung gehören die Grenzen der Aussage. Die NVD führte den Fall beim Abruf am 21. Juli noch als „Awaiting Analysis“. Der veröffentlichte CVSS-v3.1-Wert 8,8 stammt aus einer Sekundärbewertung. Mastodon bezeichnet die Lücke in seinen Release Notes als kritisch und hat FFmpeg in den offiziellen Container-Images aktualisiert. Die ausgewerteten Quellen belegen jedoch keinen zuverlässig ausnutzbaren Angriffsweg über einen gewöhnlichen Mastodon-Medienupload.

    Warum betrifft FFmpeg überhaupt einen sozialen Server? Weil Mastodon hochgeladene Medien nicht nur speichert. Bilder und Videos werden analysiert und verarbeitet. Hinter der sichtbaren Timeline arbeitet deshalb eine technische Kette aus Mastodon, Ruby, PostgreSQL, Redis, Node, Webserver, Mail, Speicher und Multimedia-Bibliotheken. Wer nur die Versionsnummer der Webanwendung beobachtet, übersieht einen Teil dieser Lieferkette.

    Für Nutzer der offiziellen Mastodon-Container-Images hat das Projekt FFmpeg mit den genannten Releases aktualisiert. Bei einem systemweit installierten FFmpeg ist dagegen der Paketlieferant der Distribution zuständig. Debian, Ubuntu oder YunoHost können Sicherheitskorrekturen zurückportieren. Deshalb ist ein bloßer Vergleich mit einer Upstream-Versionsnummer kein verlässlicher Sicherheitscheck; Paket-Changelog und Security Tracker des tatsächlich eingesetzten Systems sind entscheidend.

    Patch und Migration sind zwei verschiedene Baustellen

    Ein Patch innerhalb des Zweigs 4.4 kann eine aktuelle Sicherheitskorrektur liefern. Er beseitigt aber nicht die Frist für den gesamten 4.4-Zweig. Wer bis kurz vor dem 17. Dezember wartet, bündelt mögliche Änderungen an Datenbank, Laufzeiten und Anwendung in einem hektischen Störfall.

    Die Mastodon-Dokumentation verlangt, die Hinweise aller übersprungenen Releases zu lesen. Einzelne Patchstände dürfen übersprungen werden; mindestens ein Release jedes Minor-Zweigs soll jedoch durchlaufen werden. Der Grund ist simpel: Zwischenstände können Datenbankmigrationen oder besondere Arbeitsschritte enthalten.

    Ein sauberer Migrationsplan beginnt daher mit einer Bestandsaufnahme:

    • Welcher Mastodon-Zweig und welcher Patchstand laufen tatsächlich?
    • Ist die Installation klassisch, containerisiert, über Kubernetes oder über eine Distribution beziehungsweise Plattform verwaltet?
    • Welche Versionen von PostgreSQL, Redis, Ruby, Node und FFmpeg sind eingebunden?
    • Welche Release-Hinweise gelten genau für diesen Weg?
    • Unter welchen Bedingungen wird das Update abgebrochen und zurückgerollt?

    Konkrete Universalbefehle wären hier unseriös. Ein Docker-Befehl gehört nicht auf eine YunoHost-Installation, und ein Git-Upgrade nicht auf ein distributionsverwaltetes Paket. Die Host- und Installationsart muss zuerst feststehen.

    Ein Datenbankdump ist noch kein vollständiges Backup

    Die Release Notes fordern vor dem Upgrade ein Datenbank-Backup. Die offizielle Backup-Dokumentation nennt zusätzlich die Anwendungsschlüssel, Nutzermedien und Redis.

    Diese Bestandteile haben unterschiedliche Folgen. Geht PostgreSQL verloren, verschwinden Accounts, Beiträge und Follower-Beziehungen. Fehlen die Anwendungsschlüssel, können Nutzer abgemeldet, Zwei-Faktor-Anmeldungen unbrauchbar und Web-Push-Abonnements zerstört werden. Fehlt die Medienablage, bleiben möglicherweise Texte erhalten, während Bilder und Videos verschwinden. Mastodon empfiehlt deshalb auch Offsite-Kopien.

    Ein realer Betriebsfehler sieht oft harmlos aus: Der nächtliche Datenbankdump meldet Erfolg, aber die Schlüssel liegen nur auf dem produktiven Server. Oder Datenbank und Medien werden auf denselben Datenträger gesichert, dessen Ausfall beide Kopien trifft. In beiden Fällen existiert formal ein Backup, praktisch aber kein vollständiger Rückweg.

    Technische Bewertung: Ein vorhandener Dump beweist noch keine Wiederherstellbarkeit. Erst ein dokumentierter Restore-Test zeigt, ob Datenbank, Schlüssel, Medien, Redis und Konfiguration gemeinsam wieder anlaufen. Diese Schlussfolgerung ist eine betriebliche Bewertung; sie wird nicht als wörtliche Zusage der Mastodon-Dokumentation ausgegeben.

    Der Neustart ist der Anfang der Prüfung

    Für eine klassische Installation von Mastodon 4.6.3 nennt das Projekt die erneute Asset-Kompilierung und den Neustart der Mastodon-Prozesse. Bei Docker sollen alle Mastodon-Prozesse neu gestartet werden. Die allgemeine Upgrade-Dokumentation weist darauf hin, dass ein Neustart des Streaming-Dienstes verbundene Clients trennt und durch Wiederverbindungen zusätzliche Last auslösen kann.

    Ein grüner Prozesszustand reicht deshalb nicht. Eine belastbare Abnahme prüft reale Nutzerwege:

    • Login und Zwei-Faktor-Authentisierung;
    • Textbeitrag und Medienupload;
    • Hintergrundjobs und Mailzustellung;
    • eingehende und ausgehende Föderation;
    • Last, Fehlerrate und Warteschlangen nach dem Neustart.

    Nginx, DNS und TLS können vollständig korrekt sein, während Medienjobs hängen. Die lokale Timeline kann funktionieren, während Föderation zu einer zweiten Instanz ausfällt. Ein Testbeitrag ohne Bild entdeckt keinen Fehler in der Medienverarbeitung. Monitoring muss deshalb nicht nur Prozesse, sondern den Zweck des Dienstes abbilden.

    Mastodon 4.6 bringt auch organisatorische Arbeit

    Mastodon 4.6 enthält neue Funktionen wie Collections, E-Mail-Abonnements, eine alternative Landingpage für institutionelle Server, Rollenpflichten für Zwei-Faktor-Authentisierung und Verbesserungen der Barrierefreiheit. Das sind keine Sicherheitsargumente für das Update. Sie berühren aber Kosten, Moderation und Datenschutz.

    E-Mail-Abonnements werden nicht automatisch für jedes Konto freigegeben. Administratoren können sie nach Rollen steuern, weil Newsletter-Versand Kosten erzeugen kann. Eine Community muss also entscheiden, wer senden darf, welches Volumen tragbar ist und wie Missbrauch behandelt wird.

    Collections respektieren laut Mastodon vorhandene Discovery-Einstellungen, informieren aufgenommene Personen und erlauben ihnen, das eigene Profil zu entfernen. Trotzdem braucht eine Instanz Regeln dafür, welche Sammlungen ihrem Zweck entsprechen. Die alternative Landingpage kann lokale Informationen stärker hervorheben, verlangt aber redaktionelle Pflege.

    Der technische Erfolg eines Upgrades ist somit nur eine Hälfte. Die andere lautet: Sind neue Funktionen bewusst konfiguriert, erklärt und organisatorisch getragen?

    Bewertung: Wartung ist der sichtbare Preis der Freiheit

    Meine Bewertung: Regelmäßige Sicherheitsupdates sind kein Gegenbeweis zur digitalen Souveränität. Sie zeigen ihren realen Preis.

    Zentrale Plattformen nehmen Betreibern die sichtbare Wartungsarbeit ab. Dafür behalten sie Kontrolle über Daten, Reichweite, Regeln und Konten. Selbsthosting dreht dieses Verhältnis um: Die Kontrolle kann lokal bleiben, aber Zuständigkeit und Kosten werden sichtbar. Das ist anstrengender als ein fremdes Konto. Es schafft jedoch die Möglichkeit, Code, Abhängigkeiten, Paketquellen und Migrationswege zu prüfen und den Kommunikationsraum notfalls zu übertragen.

    Das Gegenargument bleibt ernst: Ein ungepflegter eigener Server ist kein Gewinn. Ehrenamtliche Teams können nicht beliebig viele Sicherheitsmeldungen, Migrationen und Moderationsaufgaben stemmen. Genau deshalb müssen Wartungszeit, Dokumentation und Infrastruktur finanziert werden. „Open Source ist kostenlos“ ist die falsche Erzählung. Open Source macht Abhängigkeiten prüfbar und Wechsel möglich – wenn Betrieb und Recovery gemeinsam getragen werden.

    Fazit

    Der aktuelle Mastodon-Hinweis ist ein konkreter Handlungsanlass, aber kein Grund für blinden Aktionismus. Der richtige Ablauf lautet: tatsächlichen Stand feststellen, Installationsweg identifizieren, zuständige Paketquelle prüfen, vollständiges Backup erzeugen, Restore-Fähigkeit nachweisen, Release-Hinweise lesen und anschließend jeden Schritt verifizieren.

    Für Mastodon 4.4 kommt ein klarer Planungshorizont hinzu: Der Support endet am 17. Dezember 2026. Wer die Migration jetzt strukturiert, behält die Kontrolle. Wer sie verdrängt, lässt aus technischer Schuld einen Störfall werden.

    Die konkrete Version, Installationsart, FFmpeg-Paketlage und Backup-Konfiguration von treff.darknight-coffee.eu wurden für diesen Entwurf nicht geprüft. Es wird daher keine konkrete Verwundbarkeit behauptet.

    Digitale Souveränität beginnt nicht beim Download. Sie zeigt sich im Wartungsfenster – wenn eine Community ihren Server patchen, prüfen und ohne fremde Erlaubnis wieder hochziehen kann.

    Quellen

    1. Mastodon Blog, „Trunk & Tidbits, June 2026“, 17. Juli 2026:
      https://blog.joinmastodon.org/2026/07/trunk-tidbits-june-2026/
    2. Mastodon Releases 4.6.3, 4.6.2, 4.5.13 und 4.4.20:
      https://github.com/mastodon/mastodon/releases/tag/v4.6.3
      https://github.com/mastodon/mastodon/releases/tag/v4.6.2
      https://github.com/mastodon/mastodon/releases/tag/v4.5.13
      https://github.com/mastodon/mastodon/releases/tag/v4.4.20
    3. Mastodon, Sicherheitsrichtlinie:
      https://github.com/mastodon/mastodon/blob/main/SECURITY.md
    4. Mastodon-Dokumentation, „Upgrading to a new release“:
      https://docs.joinmastodon.org/admin/upgrading/
    5. Mastodon-Dokumentation, „Backing up your server“:
      https://docs.joinmastodon.org/admin/backups/
    6. Mastodon Blog, „Mastodon 4.6“:
      https://blog.joinmastodon.org/2026/06/mastodon-4.6/
    7. FFmpeg Security:
      https://ffmpeg.org/security.html
    8. NIST NVD, CVE-2026-8461, beim Abruf Status „Awaiting Analysis“:
      https://nvd.nist.gov/vuln/detail/CVE-2026-8461

    CTA

    Wie organisiert ihr Updates und echte Restore-Tests? Diskussion:
    https://treff.darknight-coffee.eu/@carrabelloy

    Podcast:
    https://podcast.darknight-coffee.org/pages/startseite

    Blog:
    https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

  • Handy flashen heißt Rückweg planen: Was postmarketOS über echte digitale Souveränität zeigt

    Stand: 19. Juli 2026
    Status: Entwurf – nicht veröffentlicht, Freigabe erforderlich

    Ein freies Betriebssystem auf dem Smartphone zu installieren, fühlt sich nach Befreiung an. Der Bootloader ist offen, das Image stammt aus einem freien Projekt, die Kontrolle scheint zurück beim Nutzer. Doch diese Freiheit wird erst beim ersten ernsten Fehler geprüft: Startet das Gerät nach einem Update noch? Gibt es einen alten Systemstand? Funktioniert die Recovery? Sind Fotos, Kontakte, Schlüssel und Zwei-Faktor-Zugänge unabhängig gesichert?

    Wer hineinflashen kann, aber nicht wieder herauskommt, ist nicht souverän. Er hat lediglich die Richtung seiner Abhängigkeit geändert.

    postmarketOS liefert im Sommer 2026 ein Lehrstück darüber, wie ein freies Projekt mit diesem Problem umgehen kann. Duranium setzt auf vollständige, verifizierte A/B-Systemabbilder und automatischen Rückfall. Ein Fallback-Bootloader soll auf geeigneten EFI-Systemen eine noch frühere Fehlerstufe absichern. usb-signaller soll USB-Modi robuster beherrschbar machen. Gleichzeitig archiviert das Projekt unbetreute Geräteports und verschärft die Anforderungen an „testing“. Das sind keine spektakulären App-Neuheiten. Es sind Bausteine praktischer Souveränität.

    Duranium behandelt Updates als vollständige Zustände

    Die offizielle Duranium-Beschreibung trennt ein schreibgeschütztes Kernsystem unter /usr vom veränderlichen System- und Nutzerdatenbereich. Aktualisierungen werden nicht als lose Folge von Paketoperationen in das laufende System geschrieben. Sie landen als vollständiges Abbild in einem inaktiven Slot. Zwei /usr-Slots bilden das A/B-Modell.[2][3]

    dm-verity prüft die Integrität des Systemabbilds. systemd-sysupdate, systemd-repart und systemd-boot übernehmen Aktualisierung, Partitionierung, Boot-Auswahl und Rückfall. Unified Kernel Images bündeln Kernel, Initramfs, Kommandozeile und Device Trees passend zur jeweiligen Systemversion. Startet die neue Version nicht erfolgreich, soll der vorherige Slot automatisch ausgewählt werden.[2][3]

    Der postmarketOS-Monatsbericht vom 6. Juli 2026 nennt eine zusätzliche Sicherung: Auf Systemen mit Unterstützung für EFI-Variablen verwendet Duranium nun systemd/bootctl, um bei einer Aktualisierung einen Fallback-Bootloader vorzuhalten.[1] Das schließt eine wichtige Lücke. Ein alter Systemslot nützt wenig, wenn ein beschädigter neuer Bootloader gar nicht mehr bis zur Slot-Auswahl kommt.

    Das Prinzip kennt jeder verantwortungsvolle Serverbetrieb. Vor einem Synapse-Upgrade reicht ein Datenbankdump nicht. Benötigt werden außerdem Medien, Schlüssel, Reverse-Proxy-Konfiguration, .well-known, die passende Softwareversion und ein dokumentierter Restore. Eine Sicherung ist erst dann ein Rückweg, wenn alle notwendigen Teile wieder zusammenspielen.

    Rollback ist nicht Recovery – und Recovery ist kein Backup

    Drei Begriffe müssen auseinandergehalten werden:

    • Rollback startet einen früheren Systemstand.
    • Recovery macht ein nicht mehr startendes Gerät wieder erreichbar.
    • Backup stellt Nutzerdaten, Schlüssel und Zugänge wieder her.

    Duranium verbessert vor allem den ersten Bereich und mit dem Bootloader-Fallback einen Teil des zweiten. Daraus folgt kein universeller Backup-Prozess für Kontakte, Nachrichten, Fotos, App-Daten oder Zwei-Faktor-Zugänge. Ein A/B-System schützt nicht automatisch den veränderlichen Datenbereich.

    Auch ein formal erfolgreicher Start beweist nicht, dass die neue Version im Alltag funktioniert. Telefonie kann ausfallen, die Kamera kann streiken oder eine Netzwerkfunktion kann erst nach dem Boot versagen. Automatischer Rückfall braucht erkennbare Fehlerkriterien. Die ausgewerteten Quellen belegen das grundsätzliche Boot-Zähler- und Rollback-Design, aber keinen lückenlosen Umgang mit jedem denkbaren Gerätefehler.[3]

    Hinzu kommt: Duranium wird ausdrücklich als „work in progress“ beschrieben. Das Projekt sucht Tester und richtet sich noch nicht an Menschen, die ein garantiert verlässliches Alltagsgerät benötigen. UEFI ist erforderlich; auf Android-Geräten soll eine geeignete U-Boot-Umsetzung die Schnittstelle liefern. Die A/B-Slots und Verity-Daten benötigen zusätzlichen Speicher. Nicht jedes postmarketOS-Gerät wird das Modell unterstützen. In der Einführung vom März waren Secure Boot und eine vollständige Verified-Boot-Kette noch nicht umgesetzt.[2]

    USB ist im Fehlerfall eine Wartungstür

    usb-signaller wurde laut Monatsbericht in den Entwicklungszweig edge aufgenommen.[1] Die Neuimplementierung für mobile Geräte mit Mainline-Linux behält eine mit usb-moded kompatible D-Bus-Schnittstelle. Dokumentiert sind transaktionales Umschalten zwischen USB-Modi, klareres Logging, Unterstützung für systemd und OpenRC sowie seit Version 0.3.0 der Rollenwechsel zwischen Geräte- und Hostfunktion.[7]

    Scheitert die Aktivierung eines USB-Gadgets, ist ein Rückfall auf reines Laden vorgesehen. Gleichzeitig steht universelle Kabelerkennung weiterhin auf der Roadmap. Die Aufnahme in edge bedeutet also weder, dass usb-signaller Teil jeder stabilen Installation von Version 26.06 ist, noch dass sämtliche USB-Funktionen auf jedem Gerät belastbar arbeiten.

    Diese Abgrenzung ist praktisch wichtig. Laden, MTP, Netzwerk-Tethering, Hostmodus und Entwicklerzugriff sind unterschiedliche Funktionen. Ein Ladesymbol beweist keinen funktionierenden Diagnoseweg. Das ist vergleichbar mit einem Reverse Proxy: Dass Nginx läuft, sagt noch nichts darüber aus, ob der Upstream-Dienst antwortet.

    Warum postmarketOS Geräte archiviert

    Über Jahre verlangte postmarketOS bei Gerätepaketen nicht zwingend einen Maintainer im APKBUILD. Nach Darstellung des Projekts entstanden dadurch mehrere hundert unbetreute Geräte-, Kernel- und andere Pakete. Einige bauten mit einem aktuellen GCC nicht mehr.[5]

    Nach Version 26.06 wurden unbetreute Gerätepakete in die Kategorie archived verschoben.[1][4] Das bedeutet:

    • Der Port wird in der normalen Geräteauswahl nicht angeboten.
    • Es werden keine Binärpakete dafür gebaut.
    • Die Dateien bleiben als Entwicklungsgrundlage erhalten.
    • Der Port kann zurückkehren, wenn Betreuung und Anforderungen wieder erfüllt sind.

    Archivieren ist hier kein Löschen und kein Verbot. Es ist eine ehrliche Kennzeichnung. Ein vorhandener Geräteordner ist so wenig ein gepflegtes Produkt wie ein altes Container-Image ohne Maintainer, Sicherheitsupdates und reproduzierbaren Build.

    Auch die Kategorie testing muss nüchtern gelesen werden. Der Kernel muss mindestens so neu sein wie der älteste noch unterstützte LTS-Kernel von kernel.org und mit LLVM gebaut werden. Port und Abhängigkeiten müssen bauen, das Gerät muss starten.[4] Trotzdem können wenige oder viele Funktionen vorhanden sein. Maintainer müssen keinen Nutzersupport leisten, und Geräte können ohne Vorankündigung archiviert werden. Version 26.06 führte 254 Geräte in testing.[6] Das sind 254 Entwicklungsstände, nicht 254 garantierte Alltagstelefone.

    Hardwaretests sind Infrastruktur, keine Garantie

    postmarketOS baut eine eigene Hardware-CI mit realen Testgeräten, steuerbarer Stromversorgung, Gateway und GitLab-Anbindung auf. Für die höchste Kategorie main verlangt das Projekt Hardware-CI an mindestens zwei Orten mit zusammen mindestens drei Geräten sowie ein Maintainer-Team von mindestens fünf Personen.[4][8]

    Das ist der richtige Ansatz: Ein Kernel, der kompiliert, beweist noch keine funktionierende Hardware. Zugleich bezeichnet die Dokumentation die Testinfrastruktur selbst als „Work-In-Progress“ und warnt vor Instabilität.[8] Automatisierte Tests reduzieren Blindflug; sie garantieren nicht jede reale Nutzungssituation.

    Klar gekennzeichnete Bewertung

    Meine Bewertung: postmarketOS handelt richtig, wenn es weniger verspricht und dafür genauer benennt, was tatsächlich getragen wird. Eine lange Geräteliste ohne Maintainer, aktuellen Kernel und getesteten Wiederanlaufweg ist keine digitale Souveränität. Sie ist eine Liste technischer Möglichkeiten, deren Betriebsrisiko vollständig beim Nutzer landet.

    Duranium setzt an der richtigen Stelle an. Atomare Abbilder, Verity, zwei Systemslots und ein Bootloader-Fallback verlagern Zuverlässigkeit aus der persönlichen Improvisation in die Architektur. Das ist politisch relevant: Proprietäre Ökosysteme verkaufen Bequemlichkeit durch zentrale Kontrolle. Ein freies System muss dem nicht mit romantischer Bastlerfreiheit antworten, sondern mit nachvollziehbarer, dezentral wartbarer Verlässlichkeit.

    Es gibt berechtigte Einwände. A/B-Slots kosten Speicher. Ein unveränderliches Kernsystem begrenzt Flexibilität. Strenge Kategorien können Nischengeräte aus dem sichtbaren Angebot drängen. UEFI- und U-Boot-Anforderungen schließen Hardware aus. Diese Kosten verschwinden nicht. Aber schwache Unterstützung als fertige Freiheit auszugeben, wäre die schlechtere Antwort. Die tragfähige Antwort lautet: Maintainer finanzieren, Hardwaretests ausbauen, Wiederherstellung dokumentieren und Grenzen offen benennen.

    Was vor jedem Flash-Vorhaben geklärt sein muss

    Dies ist kein universeller Flash-Leitfaden. Gerätespezifische Schritte dürfen erst nach Prüfung der offiziellen Dokumentation formuliert werden. Vorher sollten mindestens diese Fragen beantwortet sein:

    1. In welcher Kategorie steht genau dieses Modell: main, community, testing, downstream oder archived?
    2. Gibt es aktive Maintainer und einen noch gepflegten Kernel?
    3. Welche Funktionen sind aktuell belegt – Telefonie, Kamera, Verschlüsselung, USB?
    4. Liegen Originalabbild, offizieller Recovery-Weg und benötigte Werkzeuge vor?
    5. Sind Kontakte, Nachrichten, Schlüssel, Fotos und Zwei-Faktor-Zugänge getrennt gesichert?
    6. Gibt es für das Wartungsfenster ein Ersatzgerät oder einen anderen Kommunikationskanal?
    7. Wurde der Restore auf Lesbarkeit und Umsetzbarkeit geprüft?

    Fazit

    Digitale Souveränität ist nicht die einmalige Erlaubnis, ein anderes System zu installieren. Sie ist die dauerhafte Fähigkeit, Zustände zu prüfen, Fehler zu erkennen und nach einem Ausfall handlungsfähig zu werden.

    postmarketOS ist mit Duranium, usb-signaller, ehrlicher Geräteklassifizierung und Hardware-CI noch nicht am Ziel. Doch das Projekt bearbeitet die richtige Frage: nicht nur, wie ein freies System auf das Gerät kommt, sondern wie Nutzer nach einem Fehler wieder zurückkommen.

    Ein Gerät ist erst dann praktisch souverän, wenn der Weg hinein nicht zur Einbahnstraße wird.

    Quellen

    1. postmarketOS, „postmarketOS in 2026-06: Plasma 6.7“, 6. Juli 2026: https://postmarketos.org/blog/2026/07/06/pmOS-update-2026-06/
    2. postmarketOS, „Introducing Duranium: a more reliable postmarketOS“, 17. März 2026: https://postmarketos.org/blog/2026/03/17/introducing-duranium/
    3. postmarketOS GitLab, duranium-build/DESIGN.md: https://gitlab.postmarketos.org/postmarketOS/duranium-build/-/blob/main/DESIGN.md
    4. postmarketOS-Dokumentation, „Device Categorization“: https://docs.postmarketos.org/pmaports/main/packaging/device-categorization.html
    5. postmarketOS, „Unmaintained devices to be archived after v26.06“, 24. März 2026: https://postmarketos.org/devel/2026/03/24/archiving-unmaintained-devices/
    6. postmarketOS, „v26.06: Alpen Avocado“, 21. Juni 2026: https://postmarketos.org/blog/2026/06/21/v26.06-release/
    7. Dylan Van Assche, usb-signaller: https://codeberg.org/DylanVanAssche/usb-signaller
    8. postmarketOS-Dokumentation, „Hardware Continuous Integration“: https://docs.postmarketos.org/hardware-ci/index.html
    9. Linux Kernel Archives, „Active kernel releases“: https://www.kernel.org/releases.html
    10. postmarketOS, „State of postmarketOS“: https://postmarketos.org/state/

    CTA

    Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
    Podcast: https://podcast.darknight-coffee.org/pages/startseite
    Blog: https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.