Mozilla ist kein einzelnes Unternehmen, sondern besteht aus einer Gruppe verschiedener Organisationen, darunter die Mozilla Foundation und die Mozilla Corporation, ebenso wie MZLA Technologies Corporation, Mozilla.ai sowie Mozilla Ventures. Mit der Gründung drei weiterer Organisationen schafft Mozilla zusätzliche Komplexität im Unternehmens-Organigramm. Dieser Artikel erklärt die Rollen der neuen Organisationen. Eine weitere Mozilla-Organisation gibt es dafür mittlerweile nicht mehr.

Mozilla ist komplexer strukturiert, als es viele annehmen. Noch am ehesten bekannt ist, dass es mit der Mozilla Foundation eine Non-Profit-Stiftung gibt, die über allem steht, und Firefox von der Mozilla Corporation entwickelt wird. Vielleicht hat man auch schon gehört, dass Entwicklerin von Thunderbird die MZLA Technologies Corporation ist. Vor wenigen Jahren schrieb ich einen ausführlichen Artikel über die Organisations-Struktur von Mozilla, um die unterschiedlichen Rollen zu erklären. Dies schließt ebenfalls Mozilla.ai sowie Ventures ein. Nun hat Mozilla seine Organisations-Struktur erweitert.

Mozilla.org

In der Hierarchie der Mozilla-Organisationen waren die Mozilla Corporation, MZLA Technologies Corporation, Mozilla.ai und Mozilla Ventures bisher direkte Tochterunternehmen der gemeinnützigen 501(c)(3)-Stiftung Mozilla Foundation. Zwischen der Mozilla Foundation und den eben genannten Organisationen liegt nun die neu gegründete Organisation Mozilla.org, ebenfalls eine 501(c)(3)-Organisation. Sie verantwortet die langfristige Strategie, Finanzierung, Investitionen und Markenführung für sämtliche Mozilla-Organisationen. Damit kann sich die Mozilla Foundation komplett auf ihre philanthropischen Ziele fokussieren.

Mozilla Data Collective

Ende des vergangenen Jahres hatte ich bereits über die Datenplattform Mozilla Data Collective geschrieben, über welche Organisationen und Menschen Datensätze für andere zur Verfügung stellen können. Auch der Download von Mozillas eigenen Common Voice-Datensätzen für die Entwicklung von Sprachtechnologie erfolgt mittlerweile über diese Plattform.

Ursprünglich als Projekt der Mozilla Foundation gestartet, hat Mozilla aus dem Mozilla Data Collective eine eigene Organisation gemacht. Diese hat ihren Sitz nicht wie alle anderen Mozilla-Organisationen in den USA, sondern in England, weil man dort die Anforderungen für diese Art von Projekt am besten erfüllt sieht.

Mozilla Management Company

Eine weitere neu gegründete Organisation hört auf den Namen Mozilla Management Company. Dabei handelt es sich um eine sogenannte Public Benefit Corporation, welche die anderen Mozilla-Organisationen unterstützen soll, indem unter anderem gemeinsame Koordinationsaufgaben übernommen werden.

Mozilla Online gibt es nicht mehr

Die Beijing Mozilla Online Ltd. war ein Tochterunternehmen der Mozilla Corporation, welche sich um den Vertrieb von Firefox in China gekümmert hatte. Dieses wurde bereits Ende des vergangenen Jahres abgewickelt.

Übersicht über die Organisations-Struktur von Mozilla

Dieser Artikel fokussierte sich auf die neuen beziehungsweise eine nicht länger existierende Organisation. Auf meiner neuen Website mozilla-insights.org habe ich den Aufbau der verschiedenen Mozilla-Organisationen übersichtlich visualisiert und liefere weitere Details zu den Aufgaben aller Mozilla-Organisationen.

Der Beitrag Mozilla erweitert seine Struktur um drei weitere Organisationen erschien zuerst auf soeren-hentzschel.at.

Mit Mozilla Insights habe ich eine neue Website gestartet, welche komplexe Fakten über Mozilla recherchiert und visualisiert: Von Mozillas Organisations-Struktur über die Entwicklung der Finanzen, einer Darstellung von Investitionen und Geschäftsübernahmen bis zu einer Auflistung von Produkten, die Mozilla mittlerweile eingestellt hat.

Auf mozilla-insights.org finden interessierte Nutzer ab sofort übersichtliche Visualierungen von Fakten über Mozilla, die im Rahmen eines einzelnen Blog-Artikels untergehen würden und welche nirgends sonst in dieser Form zu finden sind. Sämtliche Inhalte stehen sowohl in deutscher als auch in englischer Sprache zur Verfügung.

Start mit diesen vier Themen

Organisations-Struktur von Mozilla

In der öffentlichen Wahrnehmung vieler Menschen gibt es wahrscheinlich einfach nur ein „Mozilla”. Mancher hat vielleicht schon von der Unterscheidung zwischen der gemeinnützigen Mozilla Foundation und der Mozilla Corporation gehört, die unter anderem Firefox entwickelt. Dass Thunderbird von der MZLA Technologies Corporation entwickelt wird, könnte fast schon als Fachwissen gelten. Tatsächlich ist das Organisations-Organigramm von Mozilla aber noch komplexer, mit mittlerweile acht verschiedenen Mozilla-Organisationen.

So geht es in diesem ersten Modul darum, die Hierarchie der Mozilla-Organisationen abzubilden und zu erklären, was die Aufgaben jeder einzelnen Organisation sind.

Finanzen

Mozilla veröffentlicht seit 2005 in jedem Jahr einen neuen Finanzbericht, aus welchem hervorgeht, wie viel Geld Mozilla eingenommen hat, wie hoch die Ausgaben waren und was das für die Entwicklung von Mozillas Vermögen bedeutet. Zwar berichten darüber Jahr für Jahr zahlreiche IT-Medien (mit dem letzten Finanzbericht als auffällige Ausnahme, über den kaum eine andere Seite als meine berichtete), aber wie die unterschiedlichen Zahlen relativ zu anderen Jahren einzuordnen sind, lässt sich ohne entsprechende Visualisierung nur schwer vermitteln.

Mozilla Insights bietet zwei Darstellungsformen: Ein Diagramm zeigt den Verlauf von Einnahmen, Ausgaben und Vermögen, wobei jeder dieser drei Graphen ein- und ausschaltbar ist. Außerdem zeigen bestimmte Marker, in welchen Jahren ein neuer Suchmaschinen-Vertrag als wichtigste Einnahmequelle abgeschlossen worden ist. Auch lassen sich Start- und Enddatum des Diagramms beliebig verändern, falls einen die Entwicklung nur in einem bestimmten Zeitraum interessiert.

Wer mit Tabellen mehr anfangen kann, findet auch diese Form der Darstellung. Damit wird die Veränderung zum Vorjahr jeweils in Prozent angegeben.

Am Ende folgen neben einer kleinen Einordnung der Zahlen noch eine Übersicht von Artikeln, die ich über Mozillas Finanzberichte geschrieben habe, sowie eine Auflistung der Original-Quellen.

Investitionen und Akquisitionen

Mozilla hat in der Vergangenheit bereits in zahlreiche Unternehmen investiert. Durch die Gründung von Mozilla Ventures Ende 2022 haben derartige Aktivitäten stark zugenommen. Aber Informationen darüber zu finden, in welche Unternehmen Mozilla investiert hat, ist sehr schwierig. Vor allem, da Mozilla selbst nur einen kleinen Teil seiner Investitionen öffentlich kommuniziert. Meine Datenbank umfasst Stand heute 68 Investitionen sowie fünf Geschäftsübernahmen seit dem Jahr 2012 – einen so umfassenden Überblick über Mozillas Aktivitäten außerhalb der eigenen Produkte gibt es nirgends sonst.

Für jede Investition und Übernahme gibt es Informationen über den Zeitpunkt, die Art des Unternehmens sowie weitere Details, sofern bekannt. Dies kann unter anderem die Finanzierungsrunde bedeuten, den Betrag, den Mozilla für eine Übernahme bezahlt hat, oder ob es das Unternehmen vielleicht gar nicht mehr gibt. Abgerundet wird wird das Ganze durch Links zu den Unternehmens-Websites sowie Artikel-Links, falls ich darüber berichtet habe.

Für Nutzer stehen eine Filterung nach Investition und Akquisition, eine Sortierung nach Zeitpunkt oder Alphabet sowie eine Suchfunktion zur Verfügung.

Eingestellte Produkte

Das vierte Modul ist Mozillas Produkt-Friedhof. Mozilla hat in der Vergangenheit schon einige Produkte und Dienste angeboten, die es heute aus unterschiedlichen Gründen nicht mehr gibt. Wirklich alles zu nennen, was Mozilla jemals entwickelt hat, würde den Rahmen sprengen. Der Fokus dieser Auflistung liegt auf Dingen, die eine nennenswerte Nutzer-Relevanz hatten und daher besonders erwähnenswert sind. Es ist ein Bereich, in welchem ehemalige Mozilla-Produkte noch einmal gewürdigt werden sollen. Stand heute werden 31 Produkte gelistet. Auch hier steht eine Suchfunktion zur Verfügung.

Jedes eingestellte Produkt wird neben dem Namen mit einem Kategorie-Label, einer Beschreibung sowie einer Darstellung der Lebenszeit angezeigt. Falls aus einem Produkt andere Dinge enstanden sind, wird dies ebenfalls erwähnt. Und auch hier gibt es wieder Links zu Artikeln, sofern ich über die Einstellung berichtet habe.

Mozilla Insights ist für Menschen – aber auch für Maschinen

Mozilla Insights wurde in erster Linie für Menschen entwickelt, die sich für Themen rund um Mozilla interessieren. Entsprechend lag ein großer Fokus auf einer ansprechenden Darstellung, nachvollziehbaren Interaktionen und einer optimalen Performance – ob ein Wechsel der Seite oder der Sprache, alles funktioniert umgehend und ohne Wartezeiten.

Aber gerade in Zeiten von Künstlicher Intelligenz (KI), ist es umso wichtiger, Inhalte auch maschinenlesbar darzustellen. Wenn Nutzer in der Suchmaschine ihrer Wahl eine Frage zu Mozilla formulieren, soll Mozilla Insights die Fakten liefern, nach denen die Nutzer suchen. Über Mechanismen wie strukturierte Daten sowie llms.txt und llms-full.txt auf Deutsch und Englisch werden mit jedem neuen oder aktualisierten Eintrag über das eigens entwickelte CMS automatisch aktualisierte maschinenlesbare Daten bereitgestellt.

Mozilla Insights ist auch ein Community-Projekt

Mozilla Insights hat den Anspruch, eine zuverlässige Quelle zu Themen zu sein, die ansonsten nur schwer zugänglich sind. Und hierbei kann die Community helfen: Die Seite bietet eine Kontaktmöglichkeit an, die jederzeit genutzt werden darf, um auf Fehler oder komplett fehlende Daten aufmerksam zu machen. Auch Vorschläge können darüber gemacht werden, wenn zum Beispiel jemand der Meinung ist, unter „Eingestellte Produkte” sollte noch ein Produkt angezeigt werden, welches bislang fehlt.

Bislang deckt die Website vier große Themenbereiche ab. Gerne dürfen über das Formular oder auch unter den Kommentaren dieses Artikels Vorschläge für weitere Inhalte gemacht werden, die in Zukunft Platz auf Mozilla Insights finden könnten.

Mozilla Insights unterstützen

In die Entwicklung dieses Projekts sowie in die Datenpflege ist sehr viel Zeit investiert worden. Wer das Projekt unterstützen möchte, kann dies tun, indem der Welt von Mozilla Insights erzählt wird. Auch würde ich mich sehr über eine kleine Spende freuen, um die laufenden Kosten zu decken und weitere Entwicklungszeit zu ermöglichen.

Der Beitrag Mozilla Insights recherchiert und visualisiert Fakten über Mozilla erschien zuerst auf soeren-hentzschel.at.

Von Thundermail, dem E-Mail-Dienst der Thunderbird-Macher, gibt es nun eine erste Version einer Weboberfläche. Außerdem steht ab sofort für mehr Sicherheit eine Zwei-Faktor-Authentifizierung zur Verfügung.

Thunderbird ist vor allem für seinen kostenlosen E-Mail-Client für Windows, macOS und Linux bekannt. Seit November 2024 gibt es Thunderbird auch für Android, Thunderbird für iOS ist in Entwicklung. Doch dabei soll es nicht bleiben: Die MZLA Technologies Corporation möchte ein Ökosystem aus Clients und Diensten als Alternative zu denen der Tech-Giganten wie Google Mail und Microsoft Office 365 etablieren, welches Open Source ist.

Zwei-Faktor-Authentifizierung

Um die Sicherheit zu erhöhen, haben Thundermail-Nutzer ab sofort die Möglichkeit, einen zweiten Faktor zu konfigurieren, sodass Benutzername und Passwort alleine nicht mehr für einen erfolgreichen Login reichen.

Webmail Alpha

Unter webmail.thundermail.com steht eine erste Alpha-Version der Weboberfläche von Thundermail zur Verfügung. Hierüber können E-Mails gelesen, geschrieben und Kontakte verwaltet werden.

Es handelt sich dabei um einen vollständig lokal im Browser laufenden JMAP-Client, dessen Quellcode auf GitHub verfügbar ist. Das heißt auch, dass man diesen auf Wunsch auch selbst hosten kann. Es sind dafür keine serverseitigen Komponenten erforderlich. Da es sich um eine erste Alpha-Version handelt, ist der Funktionsumfang zu diesem Zeitpunk natürlich noch nicht sehr groß.

Die folgende Bilderstrecke gibt erste Eindrücke.

Der Beitrag Thundermail: Webmail Alpha und Zwei-Faktor-Authentifizierung sind da erschien zuerst auf soeren-hentzschel.at.

Kinderschutz im Netz ist ein sensibles Thema. Einerseits braucht es Schutzmechanismen, andererseits sollen diese Mechanismen nicht selbst zum Hindernis werden. Genau da setzt JusProgDNS an.

Für Icefun, die Linux-Distribution für Kinder, habe ich eine kleine grafische Applikation entwickelt, mit der sich die DNS-Einstellungen der aktiven Internetverbindung bequem auf die JusProgDNS-Altersstufen umschalten lassen. Die Idee dahinter war, eine sichere und kindgerechte Filterung von Inhalten zu ermöglichen, ohne dabei mit unnötigen Einstellmöglichkeiten zu überfordern. Viele Eltern oder Betreuende möchten einfach nicht jedes Mal in Netzwerkkonfigurationen eintauchen, wenn ein DNS-Profil geändert werden soll. Ich wollte deshalb eine Lösung schaffen, die sich in den Alltag einfügt und ohne Spezialwissen funktioniert.

Wie die Anwendung funktioniert

Die App erkennt die primäre Internetverbindung und setzt dort die DNS-Einstellungen auf das ausgewählte JusProgDNS-Profil. Auf Wunsch lässt sich die Konfiguration auch wieder auf den vorherigen Zustand zurücksetzen. Das ist wichtig, weil man nicht nur zwischen verschiedenen Altersstufen wechseln, sondern auch jederzeit zur Standardkonfiguration zurückkehren können soll.

Technisch basiert die Lösung auf NetworkManager und greift auf die Verbindung zu, die aktuell die Default-Route bereitstellt. Das bedeutet, dass gezielt nur die aktive Verbindung angepasst wird. 

Die App lässt sich systemweit installieren und erscheint dann wie eine normale Desktop-Anwendung im Menü. 

Auch wenn die JusProgDNS-App technisch gesehen nicht gross ist, war das Projekt für mich wichtig. Ich mag Software, die eine konkrete Aufgabe gut löst, statt viele Dinge halbherzig zu versprechen. Genau das ist hier der Fall. Die Anwendung macht den DNS-Wechsel einfacher und verständlicher, für Menschen, die sich nicht mit Netzwerkkonfigurationen beschäftigen möchten.

Für mich ist das auch ein anschauliches Beispiel dafür, wie Freie Software im Alltag wirken kann. Nicht jede Verbesserung muss spektakulär sein. Manchmal reicht ein kleines Tool, das eine einzige Aufgabe sauber löst, um einen echten Unterschied zu machen.

Ausblick

Momentan ist die Anwendung auf das zentrale Umschalten der DNS-Profile ausgelegt. Sie ist bewusst schlank gehalten, damit sie zuverlässig funktioniert und sich leicht bedienen lässt. Denkbar wären später noch kleine Ergänzungen, etwa bessere Rückmeldungen in der Oberfläche oder zusätzliche Hinweise zu den einzelnen Profilen.

Für mich war aber zuerst wichtig, eine stabile und verständliche Basis zu schaffen. Genau die ist jetzt vorhanden. Und ich hoffe, dass die App im Alltag einen kleinen, aber hilfreichen Dienst leistet.

Quellcode: https://codeberg.org/Lioh/JusProgDNS

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

Neue Feature-Updates von Firefox erscheinen bisher in der Regel alle vier Wochen. Beginnend mit Firefox 154 werden neue Funktions-Updates im Abstand von jeweils zwei Wochen erscheinen.

Zwischen zwei Funktions-Updates von Firefox liegen bisher normalerweise exakt vier Wochen. Nachdem Mozilla im Mai bereits damit gestartet hat, mindestens ein Korrektur-Update pro Woche zu veröffentlichen, erhöht Mozilla nun auch bei den Feature-Updates das Tempo. Ab Firefox 154, dessen Veröffentlichung für den 18. August 2026 geplant ist, werden nur noch zwei Wochen zwischen den Major-Releases liegen. Demnach wird Firefox 155 bereits am 1. September 2026 erscheinen. Damit zieht Mozilla mit Google gleich, die ab September ebenfalls auf einen Zwei-Wochen-Zyklus für Chrome umstellen werden.

Ausnahmen kann es natürlich weiterhin geben. Auch in diesem Jahr ist es wieder geplant, über den Jahreswechsel eine kleine Pause einzulegen. So werden zwischen Firefox 162 am 8. Dezember 2026 und Firefox 163 am 12. Januar 2027 fünf Wochen Abstand liegen.

Eine weitere Auffälligkeit in Mozillas aktualisiertem Veröffentlichungskalender: Die Unterstützung von Firefox ESR 115 für veraltete Versionen von Windows und macOS wurde zuletzt bis August 2026 zugesagt. Der neue Kalender kommuniziert eine Verlängerung der Lebenszeit von Firefox ESR 115 bis März 2027.

Tipp: Release-Termine von Firefox im Jahr 2026

Der Beitrag Firefox: Features-Updates künftig alle zwei Wochen erschien zuerst auf soeren-hentzschel.at.

TUXEDO OS wechselt auf Debian Testing, das offiziell keine Sicherheitsupdates garantiert. Ich habe beim Hersteller nachgefragt, wie er diese Lücke schliessen will.

TUXEDO Computers hat am 7. Juli angekündigt, TUXEDO OS künftig nicht mehr auf Ubuntu, sondern auf Debian Testing aufzubauen. Als Gründe nennt der Augsburger Hardware-Hersteller unter anderem die zunehmende Snap-Zentrierung von Ubuntu, Unzufriedenheit mit Canonicals Release-Politik und den Wunsch nach mehr Eigenständigkeit. In der Community wurde die Ankündigung überwiegend positiv aufgenommen. Ein Punkt fehlte im Blogbeitrag jedoch komplett: Wie steht es um die Sicherheitsupdates? Ich habe beim TUXEDO-Presseteam nachgefragt und Antworten erhalten.

Das Problem mit Debian Testing

Wer die Ankündigung liest, könnte meinen, Debian Testing sei einfach ein rollendes Debian mit frischeren Paketen. Technisch stimmt das, sicherheitstechnisch hat der Zweig aber eine gut dokumentierte Schwachstelle: Debian garantiert für Testing keinen offiziellen Security-Support. Das Security Team hält auf seiner Wiki-Seite unmissverständlich fest, dass Sicherheit für Testing und Unstable nicht offiziell garantiert wird. Und das Debian-Wiki zum Testing-Zweig wird noch deutlicher: Verglichen mit Stable und Unstable habe Testing die schlechteste Geschwindigkeit bei Sicherheitsupdates. Wer Sicherheit priorisiere, solle Testing nicht bevorzugen.

Der Grund liegt im Mechanismus: Debian Security Advisories (DSA) gibt es nur für Stable und Oldstable. Sicherheitsfixes erreichen Testing ausschliesslich über die reguläre Migration aus Unstable, und die dauert je nach Urgency des Uploads mindestens zwei bis zehn Tage. Blockiert eine Library-Transition, ein Release-Critical-Bug oder ein Build-Problem die Migration, wird daraus auch mal deutlich mehr. Besonders heikel sind laut Debian-Dokumentation die Monate nach einem neuen Stable-Release, wenn viele neue Paketversionen nach Unstable strömen und Sicherheitsfixes für Testing hinterherhinken. Dazu kommt: Bei Schwachstellen unter Embargo erhalten koordinierte Distributoren wie Canonical vorab Zugang und können Fixes zum Zeitpunkt der Veröffentlichung bereitstellen. Testing profitiert davon nicht.

Ein Lehrstück: die sudo-Lücke CVE-2025-32463

Wie real dieses Zeitfenster ist, zeigte sich vor gut einem Jahr. Am 30. Juni 2025 wurde CVE-2025-32463 öffentlich, eine kritische Rechteausweitung in sudo (CVSS 9.3), für die umgehend Proof-of-Concept-Code kursierte, mit dem lokale Nutzer in Sekunden eine Root-Shell erhielten. Canonical lieferte den Fix für Ubuntu mit USN-7604-1 noch am Tag der Offenlegung aus. Debian Stable war dank der konservativen Paketpolitik gar nicht erst betroffen, weil der verwundbare Code erst in einer neueren sudo-Version eingeführt worden war.

Und Debian Testing? Der Maintainer lud die gefixte Version am Morgen des Disclosure-Tags mit Urgency high nach Unstable hoch, doch der Security Tracker führte Testing weiterhin als verwundbar, während Unstable bereits gefixt war. Testing-Nutzer sassen also mindestens die zweitägige Migrationsfrist lang auf einer öffentlich exploitbaren Root-Lücke, während Ubuntu- und Debian-Stable-Nutzer geschützt waren. Spannendes Detail: TUXEDO selbst verwies damals in einer Mitteilung zur sudo-Lücke stolz darauf, dass die eigenen Sicherheitsupdates auf der stabilen Grundlage von Ubuntu basieren. Genau dieses Fundament fällt nun weg.

TUXEDO antwortet

Weil die Ankündigung all diese Punkte offenliess, habe ich dem TUXEDO-Presseteam einen Katalog mit zehn Fragen geschickt, vom grundsätzlichen Umgang mit der fehlenden Security-Garantie über konkrete Reaktionszeiten bis zu den Zusagen gegenüber Geschäftskunden. Annika Litzel aus der Presseabteilung hat alle Fragen beantwortet.

Auf die zentrale Frage, wie TUXEDO mit der dokumentierten Schwäche des Testing-Zweigs umgehen will, räumt das Unternehmen das Problem offen ein: Die Verzögerung beim Paketabgleich in Testing sei bekannt. Man wolle aber nicht mehr passiv auf die Migration aus Unstable warten:

"Wir betreiben eigene Paket-Repositories und spiegeln die Basis. Wenn kritische Lücken in Testing offenbleiben, greifen wir aktiv ein."

Was das konkret bedeutet, präzisiert TUXEDO auf Nachfrage: Bei kritischen Sicherheitslücken will man gepatchte Pakete direkt aus Unstable übernehmen oder bei Bedarf eigene Backports in die hauseigenen Repositories einpflegen, bevor die reguläre Testing-Migration abgeschlossen ist. Das ist ein bewährtes Vorgehen: Debian selbst empfiehlt Testing-Nutzern in seinem Wiki, Sicherheitsupdates direkt aus Unstable zu installieren, weil sie sonst zu lange brauchen, um Testing zu erreichen. Und auch Kali Linux, die wohl bekannteste Testing-basierte Distribution, importiert bei Bedarf neuere Pakete direkt aus Unstable, statt auf die reguläre Migration zu warten. Auch für die kritischen Phasen rund um ein Debian-Stable-Release, in denen die Testing-Migration erfahrungsgemäss besonders stockt, hat TUXEDO einen Plan: Man werde dann die Frequenz der manuellen Paket-Prüfungen erhöhen und wichtige Fixes über die eigenen Repositories an den Blockaden vorbeileiten.

Ich wollte ausserdem wissen, ob es definierte Reaktionszeiten für kritische Schwachstellen gibt, und habe dabei bewusst die eingangs erwähnte sudo-Lücke als Massstab genannt. TUXEDO verspricht, die bisherigen Reaktionszeiten beizubehalten; bei gravierenden Lücken greife ein beschleunigter QA-Prozess:

"Das Ziel bleibt eine Bereitstellung von Fixes innerhalb weniger Stunden nach Verfügbarkeit eines funktionierenden Patches."

Heikel wird es beim Thema Embargo. Grosse Distributoren wie Canonical erhalten bei koordinierten Disclosures vorab Zugang zu vertraulichen Informationen und können Fixes zum Zeitpunkt der Veröffentlichung bereitstellen. Auf die Frage, ob TUXEDO über vergleichbare Kanäle verfügt, verweist das Unternehmen auf direkte Kontakte zu Upstream-Entwicklern und Sicherheitsnetzwerken, räumt aber zugleich ein, dass dieser Zugang nicht überall besteht:

"Wo wir keinen Vorabzugang zu Embargo-Informationen haben, minimieren wir das Risiko durch ein automatisiertes Monitoring öffentlicher Quellen, um Fixes direkt beim Public Disclosure bereitzustellen."

Dieses Monitoring beschreibt TUXEDO als kontinuierliche, automatisierte Auswertung des Debian Security Trackers und relevanter CVE-Datenbanken; sicherheitsrelevante Abweichungen im Testing-Zweig fliessen demnach direkt in die Paket-Priorisierung ein. Ob die Nutzer künftig auch aktiv über den Status kritischer Fixes informiert werden, etwa über eigene Security-Advisories, lässt die Antwort offen. Eine transparente Information sei "Teil des erweiterten Konzepts".

Bleibt die Frage, warum von alledem in der Ankündigung nichts stand. Das Sicherheitskonzept sei zum Zeitpunkt der Veröffentlichung fertig gewesen, erklärt TUXEDO, man habe sich im ersten Beitrag bewusst auf Architektur und Dateisystemebene konzentriert. Ein eigener, detaillierter Beitrag zum Schwachstellen-Management und zur Paket-Infrastruktur sei in Vorbereitung. Interessant dabei: Btrfs mit Snapper, in der Ankündigung noch als zusätzliche Sicherheitsstufe beworben, ordnet das Unternehmen in seiner Antwort selbst als Fallback-Ebene ein, falls "ein eilig eingespielter Security-Patch unerwartete Seiteneffekte zeigt". Das ist die korrekte Einordnung, denn mit dem Schutz vor Schwachstellen hat das Dateisystem nichts zu tun.

Auf den scheinbaren Widerspruch angesprochen, dass TUXEDO Ubuntu zu langsame Sicherheitsupdates vorwirft und gleichzeitig auf eine Basis ohne garantierten Sicherheitskanal wechselt, dreht das Unternehmen den Spiess um: Bei Ubuntu LTS sei man oft blockiert gewesen, "wenn Canonical Patches verzögert oder fehlerhaft paketiert hat". Mit der eigenen Debian-Testing-Basis habe man nun die vollständige Kontrolle und könne Patches schneller selbst ausliefern. Geschäftskunden verspricht TUXEDO angepasste Update-Zyklen über die eigene Infrastruktur. Die Kombination aus kontinuierlichen Tests, Btrfs-Snapshots und aktivem Eingreifen sei eine "verlässliche und gleichzeitig modernere Alternative zum klassischen, oft starren Ubuntu-LTS-Modell".

Eine Einschränkung der eigenen Verantwortung nimmt TUXEDO bei der Paketbasis vor: Kernel, Browser und Grafik-Stack, die das Unternehmen schon heute unabhängig von der Distribution pflegt, machten den Grossteil der täglichen Angriffsfläche aus und blieben vollständig in eigener Hand. Der Anteil der verbleibenden Pakete, die direkt aus Testing einfliessen, sei zwar "nominell groß", betreffe aber überwiegend Bibliotheken und Werkzeuge mit geringerer Priorität für sofortige Sicherheitsfixes.

Einordnung: gute Antworten, offene Verbindlichkeit

Die Antworten zeigen: TUXEDO hat sich mit dem Problem auseinandergesetzt, und das skizzierte Konzept ist grundsätzlich der richtige Ansatz. Wer Testing als Basis wählt, muss die Sicherheitsversorgung selbst in die Hand nehmen, und genau das kündigt TUXEDO an. Trotzdem bleiben nach der Lektüre drei Fragezeichen.

Erstens die Verbindlichkeit: "Das Ziel bleibt" eine Bereitstellung innerhalb weniger Stunden, doch ein Ziel ist keine Zusage. Verbindliche Reaktionszeiten, wie sie Geschäftskunden von einem kommerziellen Anbieter erwarten dürfen, nennt TUXEDO nicht. Auch bei den konkreten Zusagen für Unternehmen bleibt es eher vage; TUXEDO verspricht "angepasste Update-Zyklen" und verweist auf Btrfs-Snapshots. Zweitens das Embargo-Problem: TUXEDO räumt indirekt ein, nicht überall Vorabzugang zu Informationen für vertraulicheelle Sicherheitslücken zu haben, und setzt dort auf automatisiertes Monitoring öffentlicher Quellen. Das bedeutet im Klartext: Wo Canonical am Tag null einen fertig getesteten Fix ausliefert, beginnt bei TUXEDO die Arbeit erst mit der öffentlichen Bekanntgabe. Bei einer Lücke vom Kaliber der sudo-Schwachstelle ist auch ein Fix "innerhalb weniger Stunden" ein relevantes Zeitfenster. Drittens die Transparenz: Eine öffentliche Information der Nutzer über den Status kritischer Fixes sei "Teil des erweiterten Konzepts". Ob das eigene Security-Advisories nach dem Vorbild von DSAs oder USNs bedeutet, bleibt offen.

Unterm Strich verdient TUXEDO Anerkennung dafür, auf kritische Nachfragen sehr schnell und inhaltlich substanziell geantwortet zu haben, was nicht selbstverständlich ist. Die eigentliche Bewährungsprobe kommt aber erst noch: beim angekündigten Blogbeitrag zum Schwachstellen-Management, der die Zusagen schriftlich und überprüfbar machen muss, und spätestens bei der nächsten kritischen Lücke, wenn sich zeigt, ob das Versprechen, Fixes "innerhalb weniger Stunden" bereitzustellen, der Realität standhält. Ich werde beides im Auge behalten.

Die Fragen beantwortete Annika Litzel, Presse und Öffentlichkeitsarbeit bei TUXEDO Computers, per E-Mail.

Quellen:
- Ankündigung von TUXEDO Computers: https://www.tuxedocomputers.com/de/Eine-neue-Grundlage-fuer-TUXEDO-OS-Umstieg-auf-Debian.tuxedo
- Debian Wiki zu Testing (Abschnitt "Considerations"): https://wiki.debian.org/DebianTesting
- Debian Wiki, Status Testing: https://wiki.debian.org/Status/Testing
- Debian Security Team: https://wiki.debian.org/Teams/Security
- Meine E-Mail als Anfrage an TUXEDO inkl. der Antwortmail von TUXEDO: https://cloud.rueegger.dev/s/g3nMg2XFS8mM9QA
- Securing Debian Manual, Kapitel 10: https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html
- Debian Security Tracker zu CVE-2025-32463: https://security-tracker.debian.org/tracker/CVE-2025-32463
- Ubuntu Security Notice USN-7604-1: https://ubuntu.com/security/notices/USN-7604-1

---

GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

Mozilla und der walisische Fußballverein Wrexham AFC haben eine mehrjährige Partnerschaft geschlossen. Ab der kommenden Saison wird Firefox die Trikots der Herren- sowie Frauenmannschaft zieren.

Der Wrexham AFC ist ein Fußballverein aus Wales, der nach der Übernahme durch die Schauspieler Ryan Reynolds und Rob Mac drei Aufstiege in Folge hingelegt hat, ab der kommenden Saison in der Championship spielt, der zweithöchsten Spielklasse im englischen Fußball, und nun von der Premier League träumt.

Dabei wird ab sofort „Firefox” auf den Trikots sowohl der Herren- als auch der Damenmannschaft stehen. Mozilla beschreibt den 160 Jahre alten Verein als einen, der beinahe für immer verloren gegangen wäre, von der Gemeinschaft, die ihn liebte, gerettet wurde und sich seitdem stetig nach oben gearbeitet hat. In dieser Geschichte erkennt sich Mozilla mit Firefox wieder. Mozilla beschreibt den Wrexham AFC und Firefox als zwei Herausforderer-Marken, die durch ihren unkonventionellen Ansatz und ihre Treue zu sich selbst leidenschaftliche globale Gemeinschaften aufgebaut haben. Seitens Wrexham heißt es: „Wir lieben Geschichten über Außenseiter, und sowohl Wrexham als auch Firefox wissen, wie es ist, gegen Giganten antreten zu müssen.”

Die Partnerschaft soll mehrere Jahre andauern und wird sich an diesem Wochenende zum ersten Mal zeigen, wenn der Wrexham AFC zu einem Freundschaftsspiel nach Krakau reist.

Der Beitrag Firefox wird Trikot-Sponsor vom Wrexham AFC erschien zuerst auf soeren-hentzschel.at.

Mozilla hat mit Firefox 152.0.5 sein wöchentliches Update veröffentlicht. Dieser Artikel beschreibt die Änderungen des neuesten Updates.

Download Mozilla Firefox 152.0.5

Mit dem Update auf Firefox 152.0.5 führt Mozilla @ecosia als Schlüsselwort für die Adressleiste ein, um eine Suche bei der Suchmaschine Ecosia zu starten.

Die Einstellungen zeigten keine gespeicherten Kreditkarten mehr an, sobald es eine gespeicherte Kreditkarte ohne Ablaufdatum gab.

Außerdem gab es noch eine Korrektur für das schrittweise ausgerollte „intelligente Fenster”.

Der Beitrag Firefox 152.0.5 bringt Schlüsselwort für Ecosia erschien zuerst auf soeren-hentzschel.at.

In diesem Artikel thematisiere ich, wie sich die Anzahl der entdeckten Schwachstellen in den letzten Jahren entwickelt hat und ob wir noch von Zero-Day sprechen, oder eher von Zero-Hour oder Zero-Minute.

Ich werde darstellen, warum es in meinen Augen bis auf wenige Ausnahmen nicht mehr angemessen ist, nur noch einmal im Jahr oder quartalsweise zu patchen und unter Schmerzen eingeübte Prozesse heute nicht mehr zeitgemäß erscheinen.

Anschließend werde ich euch bitten, eure Erfahrungen anonym mit mir zu teilen. Ich erhoffe mir, so einen besseren Überblick über die Situation da draußen in den Rechenzentren, Serverräumen und IT-Betriebseinheiten zu gewinnen. Mehr dazu unten im Text.

Entwicklung der Bedrohungslage

Die Anzahl der pro Jahr gemeldeten Schwachstellen (CVE) steigt rasant, wie folgendes Diagramm in Abbildung 1 verdeutlicht.

Während sich die Anzahl der CVE pro Jahr erstmalig im Zeitraum von 2016 bis 2017 von ca. 6.500 auf ca. 14.500 mehr als verdoppelt hat, kam es zuletzt in den Jahren 2021 bis 2024 zu einer Verdopplung. Diesmal hat sich die Anzahl jedoch von ca. 20.000 auf knapp über 40.000 gesteigert. Und diese Zahl steigt weiter. So wurden für das erste Quartal 2026 bereits 15.176 CVE gezählt.

Wenn sich dieser Trend fortsetzt, werden wir das Jahr 2026 mit deutlich mehr als 60.000 registrierten CVE abschließen. Das wären 5.000 CVE/Monat oder 164 CVE/Tag.

Gleichzeitig sinkt die mittlere Zeit von der Veröffentlichung eines CVE bis zu einem Exploit, wie Abbildung 2 zeigt.

Lag die mittlere Zeit zwischen der Veröffentlichung eines CVE und des Exploits 2023 noch bei über 4 Monaten, ist diese auf 21,5 Tage im Jahr 2025 gesunken. Für 2026 wird diese sogar mit nur noch 3 Stunden angegeben.

Noch bedrohlicher wirkt die Lage, wenn man sich ansieht, für wie viele CVE noch am gleichen Tag oder sogar vor deren Veröffentlichung ein Exploit bekannt wird (siehe Abbildung 3). Man spricht hier auch von Zero-Day-Exploits.

Im Jahr 2024 gab es für 47,9% der CVE einen Zero-Day-Exploit. Im Jahr 2025 war das bereits für mehr als die Hälfte der Fall, nämlich 53,6 %. Das Jahr 2026 ist noch in vollem Gange. Die Rate der Zero-Day-Exploits liegt mit bisher 76,9% nochmals deutlich höher.

Es wird für die Paketbetreuenden, Upstream-Entwickelnden und Software-Herstellenden Menschen immer herausfordernder, einen Patch bereitzustellen, bevor ein Exploit existiert und aktiv gegen verwundbare Systeme eingesetzt wird.

Klassische Ansätze funktionieren nicht mehr

Aus meiner beruflichen Tätigkeit als Red Hat TAM und als Sysadministator bei verschiedenen Unternehmen ist mir bekannt, dass unterschiedliche Unternehmen und Organisationen sehr verschieden mit Schwachstellen und deren Behandlung umgehen.

Allen ist gemein, dass sie für ihre Anwendungen Wartungsfenster vereinbaren, in denen z.B. Sicherheitsaktualisierungen installiert werden, um vorhandene Schwachstellen zu schließen. Einige haben einen Patchday pro Jahr, manche patchen einmal im Quartal und wieder andere monatlich. Einzelne Unternehmen können dies sogar noch schneller.

Die einen haben regelmäßig wiederkehrende Wartungsfenster, die anderen müssen diese bei Bedarf anmelden. Einige haben schlanke Prozesse, einige nutzen Change-Management nach ITIL.

Um die Integrität, Verfügbarkeit und Vertraulichkeit der eigenen Informationssysteme und deren umgebener Infrastruktur zu schützen, sind zwei Grundsätze seit vielen Jahren allgemein bekannt:

1. Installiere verfügbare Sicherheitsaktualisierungen so schnell wie möglich.
2. Nutze und implementiere Verteidigung in der Tiefe.

Die beiden Grundsätze stehen nicht in einer Entweder-Oder-Beziehung. Sie sollten beide berücksichtigt werden.

In meinen Augen ist es längst nicht mehr zeitgemäß, Sicherheitsaktualisierungen jährlich oder quartalsweise zu installieren. Eine kleine Ausnahme mögen hier Systeme bilden, deren Nutzerkreis stark eingeschränkt ist und auf die ausschließlich über wenige sehr gut gesicherte Kanäle zugegriffen werden kann.

Um es deutlich zu sagen: „Für wochen- oder tagelange Change-Management-Prozesse bleibt keine Zeit. Wer weiterhin so arbeitet, riskiert die Informationssicherheit seiner Umgebung.“

Wer alle seine Systeme einmal im Monat wartet und neustartet, bewegt sich in meiner Wahrnehmung aktuell im Mittelfeld dessen, was man im Feld findet. Doch auch hierauf darf sich niemand ausruhen. Existiert zu einem CVE ein Exploit und ein Patch, erscheint es fahrlässig, bis zu einem Monat mit dessen Installation zu warten.

Leider fehlt etlichen Unternehmen bzw. Organisationen noch immer die Fähigkeit schnell festzustellen, ob ihre IT-Dienste korrekt ausgeführt werden. Patch-Management-Zyklen sehen hier meist vor, dass zuerst einige Systeme aktualisiert werden, dann wartet man 1-2 Wochen, ob jemand meckert und dann aktualisiert man die restlichen Systeme. Das ist nicht mehr zeitgemäß.

Aus der eingangs beschriebenen Bedrohungslage folgend muss das neue Ziel lauten, jedes individuelle System an jedem Tag aktualisieren und neustarten zu können. Die Funktion von IT-Diensten ist durch automatisierte Mechanismen wie z.B. Monitoring oder automatisierte Tests zu verifizieren, um schnell mit der nächsten Stage fortfahren zu können. Wer dieses Ziel noch nicht erreicht hat, sollte sich schnellstens auf den Weg machen. Selbst wenn die 100% unerreichbar scheinen, ist jedes System, das man schnell absichern kann, ein deutlich geringeres Risiko für die eigene Informationssicherheit.

Wo Sicherheitsaktualisierungen nicht zeitnah eingespielt werden können, lässt sich das Risiko durch Verteidigung in der Tiefe minimieren. Kommunikationsverbindungen von und zu betrachteten Systemen sind zu überwachen und ggf. zu limitieren. Doch auch diese Maßnahmen müssen schnell verfügbar und umsetzbar sein. Wer erst zwei Wochen diskutieren muss, ob man den Zugriff auf einen Dienst einschränken könne, müsse, sollte, handelt nicht angemessen.

Zusammenfassend sehe ich unklare Verantwortlichkeiten, langwierige Abstimmungsprozesse und manuelle Tätigkeiten als Gift und Risiko für die Informationssicherheit. Klare Strukturen, geklärte Verantwortlichkeiten und Automation sind kein nice-to-have, sondern ein MUSS.

Wie geht ihr damit um?

Nun möchte ich von euch wissen: „Patcht ihr schon oder prozessiert ihr noch?“

Ich bin sehr daran interessiert zu erfahren, wie es in den Umgebungen meiner Lesenden und derer Bekannten zugeht. Daher freue ich mich sehr, wenn ihr (gern anonym) euer Patch-Management-Konzept, die Branche eures Unternehmens und die ungefähre Größe eurer Umgebung mit der Gemeinschaft bzw. mir teilt.

• Ihr habt euer Patch-Management im eigenen (Firmen-)Blog beschrieben? Teilt bitte den Link in den Kommentaren.
• Sendet mir gerne eine E-Mail an patchmanagement@my-it-brain.de.
• Beschreibt euer Patch-Management in den Kommentaren unter diesem Beitrag.

Evtl. werde ich eure Beispiele anonymisiert unter ausschließlicher Nennung der Branche (falls bekannt) in Vorträgen, Diskussion und weiteren Arbeiten zu diesem Thema verwenden. Bitte schreibt ausdrücklich dazu, wenn ihr dies nicht wünscht.

Ich freue mich auf eure Beiträge, Zusendungen und wenn ihr diesen Artikel in euren Netzwerken teilt.