Molly-Update-Lücke weckt Sicherheitsbedenken wegen einer älteren Signal-Anrufbibliothek
Molly hat seit drei Monaten keine aufgeführte stabile Veröffentlichung erhalten. Das wirft die Frage auf, ob die zusätzlichen Schutzmaßnahmen mit verzögerten Sicherheitskorrekturen einhergehen. Die Molly-Update-Lücke verdient Aufmerksamkeit, weil die Juli-Veröffentlichung eine ältere Anrufbibliothek nennt als jene Version, die eine veröffentlichte Sicherheitslücke bei der Beendigung von Anrufen behebt.
Stand 2. November 2026 stützen die öffentlichen Belege Bedenken über eine alternde Veröffentlichung und eine möglicherweise betroffene Abhängigkeit. Sie belegen nicht, dass Angreifer Molly-Nutzer ausgenutzt haben. Ebenso wenig klären sie, ob Mollys angepasste Bibliothek eine gleichwertige Korrektur enthält.
Im Mittelpunkt steht der Konflikt zwischen zusätzlichen Sicherheitsfunktionen und zeitnaher Wartung. Signal liefert den Upstream-Code, also die ursprüngliche Software, die Molly anpasst. Molly-Nutzer sind auf einen weiteren Veröffentlichungsprozess angewiesen, um diese Änderungen zu erhalten. Ein sicherheitsorientierter Fork, eine unabhängig gepflegte Softwarevariante, muss diesen Prozess neben seinen eigenen Schutzmaßnahmen zuverlässig halten.
Was die Molly-Update-Lücke tatsächlich zeigt
Mollys öffentliche GitHub-Veröffentlichungsliste führt v8.19.2-4 vom 31. Juli als neueste Veröffentlichung auf. Die Hinweise beschreiben eine Behebung eines DNS-Lecks, also der unbeabsichtigten Offenlegung von Domain-Abfragen, wenn ein konfigurierter Proxy verwendet wurde. Damit liegt die sichtbare stabile Veröffentlichung mehr als drei Monate hinter dem Berichtsdatum dieses Artikels. Der Veröffentlichungsverlauf stützt die zentrale zeitliche Aussage.
Die Veröffentlichungslücke ist überprüfbar; die Sicherheitsfolgen erfordern eine gesonderte Prüfung.
Diese Unterscheidung ist wichtig, weil Veröffentlichungsdaten eine engere Frage beantworten, als Schlagzeilen oft nahelegen. Sie zeigen, wann ein Projekt ein Paket über einen bestimmten Kanal veröffentlicht hat. Sie offenbaren nicht automatisch jede Änderung innerhalb dieses Pakets.
Eine ältere Veröffentlichung kann eine gezielt übernommene Sicherheitskorrektur enthalten. Entwickler nennen das einen Backport: die Übernahme einer späteren Korrektur, ohne die gesamte neuere Veröffentlichung zu übernehmen. Umgekehrt kann ein kürzlich veröffentlichtes Paket eine veraltete Abhängigkeit beibehalten.
Für Leser ist die hilfreiche Frage daher konkreter als die, ob Molly inaktiv wirkt. Entscheidend ist, ob die installierte Anwendung die Korrektur für die diskutierte Sicherheitslücke enthält.
Die öffentliche Besorgnis entstand durch einen Community-Beitrag, der mit dem Briefing zu dieser Geschichte bereitgestellt wurde. Sein Titel behauptet sowohl eine dreimonatige Update-Pause als auch eine Sicherheitslücke. Diese Behauptungen sollten bei der Überprüfung getrennt behandelt werden, auch wenn sie gemeinsam in einer Diskussionsüberschrift erscheinen.
Die Veröffentlichungsliste belegt die erste Behauptung. Die zweite zu bestätigen erfordert, die Komponenten der Anwendung mit einem dokumentierten Fehler abzugleichen und anschließend auf gleichwertige Korrekturen zu prüfen.
Dieser Ansatz begrenzt auch, was über das Projekt selbst verantwortungsvoll gesagt werden kann. Eine stille Veröffentlichungsseite beweist nicht, dass die Maintainer die Entwicklung aufgegeben haben. Sie erklärt weder ihre Verfügbarkeit noch interne Tests oder Hindernisse bei Veröffentlichungen.
Eine verifizierte Erklärung für die Pause liegt hier nicht vor. Eine solche zuzuschreiben würde ein beobachtbares Wartungsproblem in Spekulationen über die verantwortlichen Personen verwandeln.
Nutzer benötigen jedoch keine Erklärung, um zu erkennen, dass das verfügbare Paket altert. Eine private Entwicklungsarbeit bietet keinen eingesetzten Schutz, bis eine korrigierte Anwendung ihre Geräte erreicht.
Deshalb ist die Lücke jetzt relevant. Die praktische Frage betrifft die Software, die Menschen installieren können, und nicht die Absichten hinter Arbeit, die sie nicht prüfen können.
Für alle, die die Geschichte verfolgen, sollte das Juli-Datum der Ausgangspunkt der Untersuchung sein. Der Abhängigkeitsnachweis liefert das nächste, folgenreichere Beweisstück.
Eine ältere Anrufabhängigkeit macht die Sorge konkret
Der mit Molly v8.19.2-4 verbundene Quellcode deklariert seine Android-RingRTC-Abhängigkeit als im.molly:ringrtc-android:2.69.5-1. RingRTC ist die Softwarebibliothek, die Signal-bezogene Anruffunktionen verarbeitet. Die markierte Anrufabhängigkeit liefert eine konkrete Komponente zur Prüfung.
Ein veröffentlichter Sicherheitsdatensatz, CVE-2026-113380, beschreibt ein Problem bei der Anrufbeendigung in Upstream-RingRTC-Versionen vor 2.72.0. Eine CVE ist eine öffentliche Kennung zur Nachverfolgung einer offengelegten Sicherheitslücke. Der Datensatz beschreibt eine Störung der Auflegeverarbeitung, wenn ein anderer Anrufteilnehmer eine interne Warteschlange überlastet. Audio und möglicherweise auch Video können weiterhin beteiligt bleiben. Die Warnmeldung zur Anrufbeendigung wurde am 20. Oktober veröffentlicht.
Die deklarierte Abhängigkeit gibt dieser Geschichte eine technische Grundlage, die über das Alter der Anwendung hinausgeht.
Die Molly-Abhängigkeit verwendet jedoch den eigenen Paket-Namensraum und Versionssuffix des Projekts. Das schafft eine wichtige Prüfgrenze. Ihre Nummer liegt unter der behobenen Upstream-Version, doch die Nummer allein beweist keine identischen Quellinhalte.
Eine abschließende Bewertung würde die exakte Bibliothek untersuchen, die zum Erstellen der verteilten Anwendung verwendet wurde. Sie müsste feststellen, ob die relevante Korrektur oder eine funktional gleichwertige Änderung vorhanden ist.
Dieser Artikel hat diese Prüfung auf Artefaktebene nicht abgeschlossen. Ein Artefakt ist die tatsächlich verteilte Softwaredatei und nicht die Quellcodeauflistung, die beschreibt, wie sie erstellt wird.
Die Belege stützen daher eine möglicherweise betroffene Abhängigkeit und einen Klärungsbedarf. Sie rechtfertigen nicht, einen erfolgreichen Molly-spezifischen Angriff als unabhängig nachgewiesen darzustellen.
Diese Unterscheidung ist für Nutzer hilfreich, die sensible Anrufe erwägen. Sie benötigen eine Antwort über die Komponente, die auf ihren Telefonen läuft. Eine allgemeine Beruhigung über Verschlüsselung würde diese Frage nicht beantworten.
Ende-zu-Ende-Verschlüsselung, die Inhalte zwischen kommunizierenden Endpunkten schützt, bestimmt nicht für sich allein, ob ein Endpunkt die Übertragung auf Anweisung beendet. Ein Anruf kann verschlüsselt bleiben und sich dennoch entgegen den Erwartungen des Teilnehmers verhalten.
Man stelle sich hypothetisch einen Forscher vor, der ein Interview beendet, bevor er mit einer Person in seiner Nähe vertrauliches Material bespricht. Die Privatsphäregrenze liegt in dem Moment, in dem das Mikrofon aufhört, Audio zu senden.
Wenn diese Grenze versagt, stellt ein starker Schutz während der Übertragung die beabsichtigte Kontrolle des Nutzers nicht wieder her. Dieses Szenario veranschaulicht die Bedeutung des gemeldeten Fehlers; es ist kein dokumentierter Molly-Vorfall.
Dieselbe Unterscheidung gilt für Arbeitsanrufe, Quellengespräche und persönliche Gespräche. Nutzer treffen Entscheidungen danach, ob ihre Teilnahme beendet ist, häufig ohne den zugrunde liegenden Anwendungszustand zu prüfen.
Für Entwickler ist die unmittelbare Aufgabe konkret. Der Nachweis, dass die Korrektur vorhanden ist, würde mehr Unsicherheit beseitigen als der Vergleich von Anwendungsversionen oder die Wiederholung allgemeiner Sicherheitsbehauptungen.
Zusätzliche Härtung bleibt von Wartung abhängig
Molly beschreibt sich als sicherheitsorientierte Signal-Variante. Seine Dokumentation nennt Schutz durch Datenbank-Passphrase, automatische Sperrung, Speicherbereinigung und Alternativen für den Empfang von Benachrichtigungen. Dieselbe Dokumentation besagt, dass routinemäßige Updates alle zwei Wochen erscheinen und Sicherheitspatches angewendet werden, sobald sie verfügbar sind. Dies sind die vom Projekt genannten Funktionen und Wartungszusagen, nicht eine unabhängige Überprüfung ihrer Wirksamkeit. Seine Sicherheitszusagen legen den Maßstab fest, dem Nutzer vertrauen sollen.
Zusätzliche Schutzmaßnahmen und zeitnahe Korrekturen betreffen unterschiedliche Risiken, und Nutzer müssen beide getrennt bewerten.
Härtung bedeutet, Maßnahmen hinzuzufügen, die Exposition verringern oder Schäden begrenzen sollen. Eine Datenbanksperre betrifft beispielsweise den Zugriff auf auf einem Gerät gespeicherte Informationen. Eine Korrektur der Anrufbibliothek betrifft das Verhalten während der Kommunikation.
Erfolg in einem Bereich belegt keine Sicherheit im anderen. Eine Funktionsliste kann nicht beantworten, ob eine bestimmte verwundbare Komponente korrigiert wurde.
Das ist der zentrale Zielkonflikt in der Diskussion Molly vs Signal. Nutzer, die einen modifizierten Client wählen, können für sie wertvolle Kontrollmöglichkeiten gewinnen und zugleich den Integrations- und Verteilungsprozess eines weiteren Projekts akzeptieren.
Diese Abhängigkeit macht Forks nicht grundsätzlich unsicher. Sie bedeutet, dass ihr Sicherheitsargument neben der Gestaltung zusätzlicher Funktionen auch fortlaufende operative Arbeit umfasst.
Eine Upstream-Korrektur muss geprüft, integriert, erstellt, getestet, signiert und ausgeliefert werden. Die Signierung verknüpft eine Herausgeberidentität mit einem Softwarepaket, damit Geräte autorisierte Updates erkennen können.
Jede Phase kann für sich genommen sinnvoll sein. Zusammen bestimmen diese Phasen, wie lange Nutzer warten, bevor eine veröffentlichte Korrektur zu einem installierten Schutz wird.
Die Kosten sind besonders relevant, wenn Änderungen dieselben Bereiche berühren wie die Upstream-Entwicklung. Entwickler müssen ihre Änderungen erhalten und zugleich prüfen, dass neuer Code mit ihnen korrekt funktioniert.
Diese Arbeit sollte nicht als administrativer Aufwand abgetan werden. Release Engineering bildet einen Teil der Sicherheitsgrenze des Produkts, weil Nutzer auf das daraus entstehende Paket angewiesen sind.
Für jemanden, der fragt: „Ist Molly Signal sicher?“, hängt die Antwort daher vom betrachteten Risiko ab. Schutz vor beiläufigem Zugriff auf gespeicherte Nachrichten unterscheidet sich von der zuverlässigen Behandlung böswilliger Anrufteilnehmer.
Eine hilfreiche Bewertung fragt, welche Schutzmaßnahmen wichtig sind, welche Version installiert ist und welche Belege ihren Wartungsstatus stützen. Ein einzelnes Adjektiv kann diese Antworten nicht verantwortungsvoll zusammenfassen.
Das Haupt-Signal bietet einen Bezugspunkt, weil es die ursprüngliche Anwendung und Anrufbibliothek pflegt. Diese Beziehung entfernt einen nachgelagerten Integrationsschritt, bedeutet jedoch nicht Freiheit von Sicherheitslücken.
Molly muss die zusätzliche Wartungsabhängigkeit unterdessen durch die Vorteile rechtfertigen, die seine Nutzer tatsächlich benötigen. Diese Rechtfertigung wird schwieriger, wenn der Komponentenstatus unklar bleibt.
Der faire Vergleich betrifft gegenwärtiges, überprüfbares Verhalten. Er sollte weder annehmen, dass ein modifizierter Client sicherer ist, weil er Kontrollmöglichkeiten ergänzt, noch dass ein ursprünglicher Client fehlerfrei ist.
Der unmittelbare Druck liegt auf Mollys Veröffentlichungsprozess. Seine erklärten Wartungserwartungen machen die sichtbare Pause folgenreich, unabhängig von ihren Gründen.
Die Upstream-Korrektur verändert die Priorisierung der Anrufbeendigung
Signals verknüpfte RingRTC-Korrektur fügt ein separates Flag für Beendigungsanfragen hinzu und prüft die Beendigung unabhängig von der gewöhnlichen Warteschlangenverarbeitung. Ein Flag ist eine gespeicherte Zustandsmarkierung, die Code direkt prüfen kann. Die Änderung führt außerdem begrenztes Warten ein und ermöglicht, dass die Bereinigung nach bestimmten Fehlern fortgesetzt wird. Diese Details erscheinen in der Upstream-Korrektur zur Beendigung.
Die technische Bedeutung liegt in der Trennung zwischen der Anforderung, einen Anruf zu beenden, und dem Warten hinter anderer Arbeit. Die Korrektur macht die Beendigung weniger davon abhängig, dass die Warteschlange normal fortschreitet.
Die Entscheidung eines Nutzers, nicht mehr teilzunehmen, muss auch dann zuverlässig durchgesetzt werden, wenn ein anderer Teilnehmer unerwartete Aktivitäten erzeugt.
Eine Warteschlange ist eine Struktur, die Arbeit hält, bis Software sie verarbeitet. Warteschlangen sind verbreitet und nützlich, doch ihre Reihenfolge kann folgenreich werden, wenn dringende lokale Aktionen die Verarbeitung mit aus der Ferne beeinflussbaren Ereignissen teilen.
In diesem Fall betrifft die Sicherheitsfrage, wer die Verzögerung tatsächlich kontrolliert. Der lokale Teilnehmer erwartet, dass die Anwendung die Auflegeaktion auch unter ungewöhnlichen Bedingungen befolgt.
Das unterscheidet dieses Problem von einem gewöhnlichen Usability-Fehler. Eine verzögerte Animation ist unbequem. Die verzögerte Durchsetzung einer Datenschutzentscheidung kann Informationen preisgeben, die ein Teilnehmer zurückhalten wollte.
Die weitergehende Lehre ist eine technische Schlussfolgerung aus dieser Korrektur. Steuerelemente, die sensible Aktivitäten beenden, verdienen eine ausdrückliche Behandlung, wenn Software mit konkurrierenden oder feindseligen Eingaben umgeht.
Dieses Prinzip gilt über Messaging hinaus. Ein Befehl zum Stoppen einer Aufzeichnung, der Entzug einer Sitzung oder der Widerruf einer Berechtigung können ähnliche Erwartungen mit sich bringen. Jedes davon erfordert eine eigene Implementierungsprüfung; diese Schwachstelle belegt keine Fehler in jenen anderen Systemen.
Für diese Geschichte bleibt die Lehre auf Anrufe konzentriert. Die relevante Frage lautet, ob Mollys verteilte Bibliothek das mit der Korrektur eingeführte Beendigungsverhalten enthält.
Eine neuere Anwendungsoberfläche würde diese Frage nicht klären. Ebenso wenig erfolgreiche gewöhnliche Anrufe, da der Normalbetrieb nicht zwingend die hier behandelte Fehlerbedingung auslöst.
Eine sinnvolle Validierung muss die anormale Bedingung selbst untersuchen. Sie sollte belegen, dass die lokale Beendigungsanfrage zu einer vollständigen Bereinigung führt, wenn die reguläre Verarbeitung stockt oder überlastet wird.
Deshalb wären eine Quellcodeänderung, ein Build-Nachweis und ein gezielter Regressionstest zusammen überzeugend. Ein Regressionstest prüft, dass ein zuvor identifizierter Fehler nicht erneut auftritt.
Diese Evidenzformen beantworten unterschiedliche Fragen. Der Quellcode legt das beabsichtigte Verhalten fest. Der Build-Nachweis verbindet diesen Quellcode mit dem Paket. Tests untersuchen, ob das relevante Verhalten funktioniert.
Nutzer sollten nicht gezwungen sein, all diese Analysen selbst durchzuführen. Eine Erklärung der Maintainer, die die Korrektur und betroffene Releases benennt, gäbe ihnen eine praktische Grundlage für die Entscheidung, was sie installieren sollten.
Der Mechanismus erklärt auch, warum das Kalenderalter nur indirekt zählt. Zeit schafft die Möglichkeit einer Abweichung, doch das Vorhandensein oder Fehlen der Korrektur bestimmt dieses konkrete technische Risiko.
Was über Mollys Gefährdung weiterhin ungeklärt ist
Die verfügbaren Unterlagen lassen mehrere Fragen offen. Diese Prüfung hat CVE-2026-113380 nicht unabhängig gegen Molly v8.19.2-4 reproduziert. Sie hat auch nicht festgestellt, ob Mollys angepasste Calling-Bibliothek einen gleichwertigen Backport enthält.
Ebenso wurde kein erfolgreicher Angriff auf einen Molly-Nutzer nachgewiesen. Eine Warnung vor einer Schwachstelle, eine Schlussfolgerung zu einer betroffenen Komponente und ein Beleg für Ausnutzung sind unterschiedliche Feststellungen.
Die am stärksten belegte Schlussfolgerung ist eine dokumentierte Release-Lücke mit einem konkret ungeklärten Komponentenrisiko.
Diese Schlussfolgerung ist ernst genug, um eine Prüfung zu rechtfertigen, ohne sie zu unbelegten Behauptungen auszuweiten. Zu sagen, jeder Molly-Nutzer sei überwacht worden, ginge weit über die Belege hinaus.
Ebenso belegt dieses Calling-Problem nicht, dass gespeicherte Nachrichtenverläufe entschlüsselt wurden. Der gemeldete Mechanismus betrifft die Beendigung einer aktiven Kommunikationssitzung.
Eine präzise Eingrenzung hilft Nutzern, angemessene Entscheidungen zu treffen. Wer die Privatsphäre bei Anrufen prüft, benötigt andere Informationen als jemand, der Nachrichtenspeicherung oder Kontozugriff untersucht.
Die Beschreibung im Advisory betrifft einen weiteren Teilnehmer eines Anrufs. Sie beschreibt nicht, dass beliebige Fremde ohne bestehende Interaktion aus der Ferne jedes installierte Mikrofon aktivieren können.
Diese Grenze sollte sichtbar bleiben, wann immer die Geschichte zusammengefasst wird. Das Weglassen der Angriffsbedingungen kann eine Warnung dramatischer, aber weniger nützlich machen.
Das Fehlen eines reproduzierten Molly-spezifischen Exploits sollte jedoch auch nicht beruhigen. Nutzer müssen nicht auf öffentlich bekannt gewordenen Schaden warten, bevor sie Belege dafür erwarten dürfen, dass eine relevante Korrektur ausgeliefert wurde.
Hier muss eine vorsichtige Antwort auf „Ist Molly Signal sicher?“ einem binären Urteil widerstehen. Die Belege werfen eine Frage zu einem bestimmten Release und einer bestimmten Komponente auf, kein dauerhaftes Urteil über das Projekt.
Auch gibt es hier keine verifizierte Grundlage, die Verzögerung Fahrlässigkeit, Finanzierung, Krankheit oder Aufgabe zuzuschreiben. Solche Erklärungen erfordern Aussagen oder Unterlagen, die sie belegen.
Maintainer können legitimen Einschränkungen unterliegen, doch Nutzer erleben weiterhin die Folgen verzögerter Auslieferungen. Eine Ursache zu verstehen und ein Release zu bewerten, sind getrennte Aufgaben.
Auch der Vergleich Molly vs Signal sollte ebenso diszipliniert bleiben. Die Verantwortung des Upstreams garantiert keine perfekte Sicherheit, während zusätzliche Härtung Unsicherheit über bekannte Korrekturen nicht entschuldigt.
Für Organisationen spricht dies dafür, in sensiblen Arbeitsabläufen konkrete Anwendungs-Builds zu bewerten. Ein zugelassener Produktname reicht nicht aus, wenn verschiedene Clients und Releases unterschiedliche Software enthalten.
Für Einzelpersonen spricht es dafür, vor Annahmen die tatsächliche Anwendung und den Update-Kanal zu prüfen. Ein beruhigendes Symbol oder eine vertraute Kontaktliste identifiziert nicht die zugrunde liegende Abhängigkeit.
Die beste Reaktion würde die Unsicherheit mit Belegen eingrenzen. Ein dokumentierter Backport würde die Schlussfolgerung zu einer betroffenen Komponente schwächen. Ein reproduzierbarer Fehler würde sie stärken. Beides würde die Diskussion verbessern.
Drei Signale werden bestimmen, ob das Vertrauen zurückkehrt
Die Molly-Update-Lücke wird leichter zu bewerten sein, wenn öffentliche Unterlagen die relevante Korrektur mit Software verbinden, die Nutzer erhalten können. Eine weitere Debatte über allgemeine Datenschutzpräferenzen wird diese Verbindung nicht herstellen.
Die nächsten nützlichen Entwicklungen sind ein korrigiertes Release, eine ausdrückliche technische Erklärung und Belege für eine nachhaltige Auslieferung.
Das erste Signal ist ein öffentlich verfügbares Molly-Paket mit einer klar dokumentierten Korrektur der Calling-Bibliothek. Upstream RingRTC Version 2.72.0 bietet ein Referenz-Release für diese Untersuchung. Ein gleichwertiger Backport kann ebenfalls relevant sein, sofern dessen Inhalt dokumentiert ist.
Das würde das Vertrauen in das konkrete Paket stärken, indem die Komponentenfrage direkt beantwortet wird. Eine neue Version ohne relevante Informationen zu Abhängigkeiten würde Prüfern mehr Arbeit lassen.
Neben der Veröffentlichung ist die Verteilung wichtig. Nutzer benötigen das korrigierte Paket über den Kanal, den sie tatsächlich verwenden, mit ausreichenden Informationen, um zu erkennen, dass die relevante Änderung enthalten ist.
Das zweite Signal ist eine Erklärung der Maintainer, die betroffene Builds und den Status der Korrektur benennt. Eine solche Erklärung wäre besonders nützlich, wenn sie Quellcodeänderungen, Release-Identifikatoren und verfügbare Validierung miteinander verknüpft.
Eine Erklärung, die einen bestehenden Backport bestätigt, würde die Schlussfolgerung, dass das Juli-Paket diesen Fehler weiterhin enthält, wesentlich schwächen. Eine Erklärung, die die Gefährdung bestätigt, würde klären, welche Nutzer handeln müssen.
Beide Ergebnisse würden die öffentliche Dokumentation verbessern. Technische Genauigkeit ist wertvoller als eine allgemeine Zusicherung, dass Sicherheit weiterhin Priorität hat.
Das dritte Signal ist, was geschieht, nachdem das unmittelbare Problem behoben wurde. In den kommenden Monaten würden regelmäßige Releases und die ausdrückliche Behandlung von Sicherheitsänderungen zeigen, ob die Auslieferung wieder verlässlich geworden ist.
Ein einzelnes Nachhol-Release kann ein dringendes Problem lösen. Es kann für sich allein nicht belegen, wie das Projekt mit der nächsten Korrektur umgehen wird.
Wiederholte Verzögerungen würden die Sorge über die Wartungsabhängigkeit verstärken. Eine konsistente Auslieferung würde das Argument schwächen, dass Nutzer lang anhaltende Unsicherheit hinnehmen müssen, um Mollys zusätzliche Kontrollmöglichkeiten zu behalten.
Dieses letzte Signal ist wichtig, weil Vertrauen Erwartungen über künftiges Verhalten umfasst. Nutzer können den Code von morgen heute nicht prüfen, aber sie können bewerten, ob ein Projekt klar kommuniziert und Korrekturen vorhersehbar ausliefert.
Für Entwickler, die andere sicherheitsorientierte Forks pflegen, bietet dieselbe Evidenz einen praktischen Maßstab. Erklären Sie den Komponentenstatus, benennen Sie betroffene Pakete und machen Sie den Weg von der Korrektur bis zur Installation sichtbar.
Für Leser gilt: Verankern Sie die Entscheidung in Belegen, die Sie prüfen können: Ihrer installierten Version, deren dokumentierten Komponenten und dem Status relevanter Korrekturen. Behandeln Sie eine Funktionsliste nicht als Ersatz für diese Dokumentation. Wenn die Privatsphäre bei Anrufen für Ihre Arbeit oder persönliche Sicherheit wichtig ist, sollten Sie ungeklärten Wartungsfragen bei der Wahl eines Clients angemessenes Gewicht geben. Verfolgen Sie das nächste Release und dessen technische Hinweise und überprüfen Sie die Entscheidung erneut, wenn sich diese Unterlagen ändern. Die Molly-Update-Lücke wirft eine konkrete Frage auf, die eine konkrete Antwort verdient: Enthält die Anwendung auf Ihrem Gerät die Korrektur, die nötig ist, um einen Anruf zuverlässig zu beenden?
