Bitcoin Core wird einige Bugs früher offenlegen. Können Node-Betreiber rechtzeitig aktualisieren?

Bitcoin Core hat seine Sicherheitsrichtlinie zur Offenlegung geändert, nachdem Entwickler festgestellt haben, dass einige Schwachstellen mit minimalem Aufwand wiederentdeckt werden können, einschließlich eines einfachen Prompts an ein KI-Modell.

Die Richtlinienaktualisierung vom 22. Oktober des Projekts schafft einen schnelleren Weg für diese Fehler. Die Maintainer planen, so bald wie möglich eine Point-Release für jede unterstützte Hauptversion zu veröffentlichen und zusammen mit den Korrekturen eine Sicherheitswarnung zu veröffentlichen. Andere Schwachstellen behalten den bestehenden Offenlegungszeitplan. Mit der Richtlinienänderung wurde kein bestimmter neuer Fehler angekündigt, und ein KI-generierter Bericht ist nicht automatisch eine echte Schwachstelle. Die Änderung betrifft die Zeit zwischen einer verifizierten Entdeckung, einer gepatchten Veröffentlichung und öffentlichen Details.

Bitcoin-Knoten validieren Blöcke und Transaktionen lokal, und Börsen, Verwahrer und andere Dienste bauen ihre Abläufe darauf auf. Eine Veröffentlichung kann gepatchte Software für alle unterstützten Versionen verfügbar machen, doch die Betreiber dieser Systeme entscheiden, wann sie sie installieren. Bitcoin Core aktualisiert sich nicht auf jeder Maschine selbst. Die öffentliche Offenlegung kann Menschen helfen, ein Problem zu erkennen und die Korrektur zu installieren, während sie einem Angreifer Informationen gibt, die ein ungepatchter Knoten möglicherweise noch durch sein Netzwerkverhalten preisgeben könnte.

Die neue Richtlinie trennt Entdeckung von Schweregrad

Bitcoin Core hat Schwachstellen bereits nach ihren Auswirkungen und ihrer Ausnutzbarkeit als kritisch, hoch, mittel oder niedrig eingestuft. Ein remote ausgelöster Absturz unter Standardeinstellungen kann einen hohen Schweregrad haben; ein Fehler, der eine nicht standardmäßige Konfiguration erfordert oder nur begrenzte Störungen verursacht, kann niedriger eingestuft werden. Die überarbeitete Sicherheitshinweis-Richtlinie fügt eine separate Frage hinzu, wie leicht jemand das Problem finden könnte. Ihr Beispiel ist ein einfacher Prompt an ein großes Sprachmodell, aber die Kategorie ist nicht auf mit KI gefundene Fehler beschränkt.

Die Unterscheidung verhindert ein häufiges Missverständnis. „Leicht entdeckbar“ bedeutet nicht „geringer Schweregrad“. Ein Fehler kann einfach zu finden und gefährlich für betroffene Knoten sein. Umgekehrt kann ein obskures Problem bei Ausnutzung eine ernste Wirkung haben und dennoch mehr Zeit rechtfertigen, bevor die Details öffentlich gemacht werden. Die Maintainer bewerten einen Bericht während des Triage und entscheiden, ob der schnelle Weg gilt. Die veröffentlichte Richtlinie nennt das Kriterium und die geplante Reaktion, veröffentlicht aber keine mechanische Schwelle dafür, welche Prompts, Werkzeuge oder Fähigkeiten als minimaler Aufwand gelten.

Antoine Poinsot, der die Website-Änderung vorgeschlagen hat, sagte in der Pull-Request-Diskussion, dass die Maintainer mehr Berichte über Fehler erhalten hätten, die leicht wiederzuentdecken waren. Er schrieb einen Großteil der Veränderung Sprachmodellen zu, die den Aufwand verringern, bestimmte Probleme zu finden oder eine Korrektur zu identifizieren, die Entwickler diskret zu halten versuchten. Seiner Darstellung zufolge bietet das Zurückhalten von Details weniger Schutz, wenn eine andere Person die Schwäche schnell unabhängig finden kann. Dieselbe Sperrfrist kann eine korrigierte Veröffentlichung für Betreiber verzögern, die auf einem unterstützten älteren Zweig bleiben.

Für einen Bericht, der in die neue Kategorie eingeordnet wird, erklärt Bitcoin Core, dass es für jede gepflegte Hauptversion eine Point-Release mit der Fehlerbehebung und gleichzeitig eine Advisory veröffentlichen wird. „So schnell wie möglich“ beschreibt eine Absicht, nicht eine feste Anzahl von Stunden ab dem ersten Bericht. Entwickler müssen das Problem noch bestätigen, einen Patch schreiben und überprüfen, ihn in jedem Branch testen und Releases vorbereiten. Die Richtlinie verspricht nicht, dass eine nicht mehr gepflegte Version einen Patch erhält oder dass alle Betreiber aktualisiert haben, bevor die Advisory erscheint.

Die ältere Sperrfrist könnte mehrere Releases überdauern

Ordentliche Offenlegungen folgen einem anderen Zeitplan. Die Richtlinie besagt, dass Schwachstellen mit geringem Schweregrad zwei Wochen nach der Veröffentlichung einer Hauptversion, die die Fehlerbehebung enthält, offengelegt werden. Probleme mit mittlerem und hohem Schweregrad werden zwei Wochen nach dem Ende des Lebenszyklus der letzten betroffenen Version offengelegt, etwa ein Jahr nachdem eine Hauptversion die Fehlerbehebung erstmals enthielt. Die Maintainer geben zwei Wochen vor der Offenlegung eines gesperrten Problems eine Vorankündigung heraus, in der sie angeben, wie viele Schwachstellen behoben wurden und welchen Schweregrad sie haben. Kritische Fehler fallen nicht unter diesen Standardzeitplan und erfordern eine auf den Vorfall zugeschnittene Reaktion.

Die Versionshinweise zu 32.0 liefern einen konkreten Vergleich. Sie besagen, dass drei Schwachstellen mit mittlerem oder hohem Schweregrad, die in Version 30.0 behoben wurden, zwei Wochen nach dem neueren Release offengelegt werden, während in 32.0 keine Schwachstellen mit geringem Schweregrad behoben wurden, die nach diesem Zeitplan offenzulegen wären. Version 30.0 ist in der Lebenszyklustabelle von Bitcoin Core auf den 10. Oktober 2025 datiert. Der Release-Zeitplan von Version 32.0 verzeichnet dessen Tag am 21. Oktober 2026. Diese Daten liegen 376 Tage auseinander, ein arithmetischer Vergleich des älteren Fix-Datums und des neueren Tags, nicht das vom Projekt angekündigte Datum für eine einzelne Advisory.

Die Hinweise benennen weder die Komponenten noch die Ausnutzungsbedingungen dieser drei Fehler. Nach dem Standardverfahren kann eine Fehlerbehebung in einer neueren Version verfügbar bleiben, während die Details privat bleiben, bis die älteren betroffenen Branches das Wartungsfenster verlassen. Der neue Weg ändert diese Kalkulation nur für Fehler, die die Maintainer als leicht entdeckbar einstufen. Er hebt den langen Zeitplan für schwerer zu findende Fälle mit mittlerem und hohem Schweregrad nicht auf.

Eine frühere Offenlegung zeigt den älteren Weg in der Praxis. Bitcoin Core legte CVE-2024-52911 im Mai 2026 offen, nachdem der Fehler bereits in Version 29.0 behoben worden war, die im April 2025 veröffentlicht wurde. Ein speziell gestalteter Block konnte eine Use-after-free-Bedingung im Skript-Interpreter auslösen und anfällige Nodes zum Absturz bringen. Einen Block mit ausreichendem Proof of Work zu erzeugen, machte den Angriff kostspielig, und das Projekt hielt Remote-Code-Ausführung für unwahrscheinlich. Die Lücke zwischen Fehlerbehebung und öffentlichen Details war Teil des früheren Offenlegungsansatzes; sie beweist nicht, dass das alte Problem das heutige Kriterium der leichten Entdeckbarkeit erfüllt hätte.

Drei gepflegte Versionen bestimmen, wer eine Fehlerbehebung erhält

Der Software-Lebenszyklus von Bitcoin Core besagt, dass die Maintainer die letzten drei Hauptversionen unterstützen. Wenn eine neue Hauptversion erscheint, erreicht die älteste der drei das Ende ihres Lebenszyklus und erhält im Allgemeinen keine Sicherheitsfixes mehr. Da Version 32.0 am 21. Oktober getaggt wurde und ihre Versionshinweise besagen, dass Version 29.x und älter das Ende ihres Lebenszyklus erreicht haben, sind die Branches für den neuen schnellen Weg 30.x, 31.x und 32.x. Eine Point-Release für jeden dieser Branches würde es einem Betreiber von 30.x ermöglichen, einen gezielten Patch anzuwenden, ohne sofort jede Funktions- und Verhaltensänderung in 32.0 zu übernehmen.

Der Release-Candidate-Zyklus von 32.0 begann am 14. September, und das Projekt taggte die stabile Version am 21. Oktober. Die Unterscheidung zwischen einem Release-Tag, einer Binärdatei und einem installierten Node ist wichtig. Der Zeitplan zeigt ein 32.0-Tag; die offizielle Verteilung und die eigene Bereitstellung durch den Betreiber sind nachfolgende Schritte. Seine Lebenszyklus-Seite zeigte zum Zeitpunkt der Erstellung dieses Artikels noch ein „TBA“-Veröffentlichungsdatum für 32.x, obwohl der Release-Zeitplan das Tag zeigte. Die Versionshinweise zu 32.0 besagen, dass Version 29.x und älter das Ende ihres Lebenszyklus erreicht haben. Bitcoin Core hat das auf seiner Lebenszyklustabelle angezeigte Datum für 32.x noch nicht aktualisiert.

Ein Branch, der weiterhin unterstützt wird, wird nicht automatisch gepatcht. Die Richtlinie besagt, dass Fehlerbehebungen in jede gepflegte Hauptversion zurückportiert werden, und die Lebenszyklus-Seite besagt, dass die Hürde für das Zurückportieren im Allgemeinen steigt, je älter ein Branch wird. Das neue Versprechen der leichten Entdeckbarkeit ist für die Sicherheitsfehler, die es abdeckt, spezifischer. Drei gepatchte Linien zu pflegen erfordert Überprüfung und Tests über Unterschiede im Code hinweg, statt einfach einen Commit in drei Verzeichnisse zu kopieren. Eine Fehlerbehebung, die sauber auf einen Branch angewendet werden kann, kann auf einem anderen andere Arbeit erfordern. Bitcoin Core hat kein festes Zeitlimit für diese Arbeit festgelegt.

Betreiber außerhalb der drei Zweige stehen vor einer anderen Entscheidung. Version 29.x kann nach dem Ende der Lebensdauer möglicherweise noch starten und gewöhnliche Blöcke validieren, erhält aber im Allgemeinen kein neues Sicherheits-Point-Release. Ein Betreiber, der sie ausführt, muss auf einen gepflegten Zweig wechseln, um zukünftige Patches zu erhalten. Bitcoin Core empfiehlt das neueste Wartungsrelease der neuesten Hauptversion, die der Betreiber übernehmen kann. Ein Unternehmen mit benutzerdefinierten Integrationen oder Wallet-Daten benötigt möglicherweise eigene Kompatibilitätsprüfungen, bevor es diesen Schritt unternimmt. Das Ende der Lebensdauer beschreibt die Unterstützungsgrenze des Projekts, nicht einen Schalter, der alte Software an einem bestimmten Tag abschaltet.

Die Lebenszyklus-Seite von Bitcoin Core macht eine weitere Unterscheidung, die in einer Sicherheitswarnung verloren gehen kann. Eine Hauptversion ist ein Zweig, während eine Nebenversion das Wartungsupdate auf diesem Zweig ist. Jemand, der 30.0 ausführt, und jemand, der 30.3 ausführt, sind beide auf 30.x, aber sie haben nicht unbedingt dieselben Fehlerbehebungen installiert. Wenn das Projekt ein neues 30.x-Point-Release für einen leicht auffindbaren Fehler veröffentlicht, würde die bloße Meldung, dass ein Dienst „Version 30“ ausführt, keinen Schutz belegen. Die vollständige Versionsnummer und die Fixliste des Releases sind erforderlich. Deshalb lässt ein Unternehmen, das angibt, seine Nodes aktualisiert zu haben, ohne den eingesetzten Build zu nennen, die zentrale Frage unbeantwortet.

Die Versionshinweise für Version 32.0 beschreiben, wie ein normales Upgrade damit beginnt, die alte Software herunterzufahren und zu warten, bis sie beendet ist, bevor die Ersatzversion installiert wird. Node-Betreiber mit Transaktionsindizes, Wallets oder verbundenen Anwendungen haben möglicherweise zusätzliche Prüfungen durchzuführen. Die Dokumentation des Projekts besagt, dass Wartungsreleases normalerweise keine größeren neuen Funktionen einführen, was ein gepatchtes Point-Release enger macht als einen Sprung auf einen neuen Hauptzweig. Jede Bereitstellung muss dennoch gegen die umgebende Software getestet werden.

Der Patch kann öffentlich sein, bevor die meisten Nodes ihn installieren

Bitcoin Core hat keinen zentralen Betreiber, der ein Update auf jeden Node übertragen kann. Eine Einzelperson, die einen Heim-Node betreibt, lädt möglicherweise kurz nach dem Erscheinen einer Warnung ein Release herunter. Ein Verwahrer oder eine Börse testet ein Upgrade möglicherweise gegen interne Dienste, Wallet-Systeme und Monitoring, bevor Produktions-Nodes geändert werden. Ein Mining-Pool hat einen weiteren Satz von Validierungs- und Blockbau-Abhängigkeiten. Dies sind betriebliche Möglichkeiten, keine gemessene Liste darüber, wie schnell jede Gruppe ein bestimmtes Bitcoin-Core-Update installiert hat; die Richtlinienänderung wurde nicht von einer Adoptionszählung begleitet.

Eine öffentliche Warnung verändert die Informationen, die beiden Seiten zur Verfügung stehen. Sie kann die betroffenen Versionen, die Auswirkungen und die Fehlerbehebung beschreiben, damit Betreiber handeln können. Sie kann auch jemandem Hinweise geben, der alte Nodes auf dieselbe Schwachstelle testet. Poinsots Argument ist, dass der Angreifer einen leicht auffindbaren Fehler möglicherweise auch ohne die Warnung findet, während Betreiber weniger Gelegenheit zum Patchen haben, wenn korrigierte Point-Releases bis zu einer späteren Hauptversion zurückgehalten werden. Diese Position ist ein Grund, die Reparatur zu beschleunigen, kein Beweis dafür, dass die Exposition verschwindet, sobald das Release live geht.

Die Art der Verteilung ist ebenso wichtig wie die Benachrichtigung. Ein Node-Betreiber muss die korrekte Binärdatei oder das Quellpaket beschaffen, deren Authentizität im Rahmen des Release-Prozesses des Projekts prüfen, die aktuelle Software sicher stoppen und mit einer für die Bereitstellung geeigneten Version neu starten. Eine Warnung in sozialen Medien ist kein Ersatz für das signierte Release und die offizielle Warnung. Die Versionshinweise zu Bitcoin Core 32 weisen Benutzer an, eine ältere Version herunterzufahren und zu warten, bis sie beendet ist, bevor neue Software installiert wird. Die Schritte sind alltäglich, aber eine überstürzte Produktionsänderung kann eine eigene Ausfallzeit verursachen, wenn die Dienstabhängigkeiten nicht bereit sind.

Automatisches Monitoring kann einer Organisation helfen, ein Release zu bemerken. Es kann nicht entscheiden, ob ihr laufender Node von einer Schwachstelle betroffen ist, die von einer bestimmten Funktion oder Konfiguration abhängt. Eine Warnung sollte genügend Details liefern, um die relevanten Systeme zu priorisieren. In der Zeitspanne zwischen Veröffentlichung und Bereitstellung bleiben netzwerkseitig erreichbare Nodes ein praktisches Anliegen. Das Projekt hat keine gemessene Medianzeit für Betreiber veröffentlicht, um Wartungsreleases zu installieren, sodass die Frage in der Überschrift mit Stand vom 24. Oktober nicht mit einer netzwerkweiten Zahl beantwortet werden kann.

KI-Berichte erfordern eine Überprüfung vor jeder öffentlichen Warnung

Das Bitcoin Red Team hat ein eindrucksvolles Beispiel für den Umfang geliefert, den KI-gestützte Überprüfungen erzeugen können. Im August berichtete crypto.news über 4.962 potenzielle Probleme in 390 Bitcoin-bezogenen Projekten während der ersten 29,8 Stunden der Überprüfung durch die Gruppe. Die Gruppe stufte 720 als hoch oder kritisch ein und erklärte, dass mehr als ein Fünftel der potenziellen Befunde zum Berichtszeitpunkt reproduziert worden sei. Dies sind die Zahlen der Gruppe für eine Reihe von Projekten, keine Zählung von Bitcoin-Core-Schwachstellen oder eine verifizierte Bilanz ausnutzbarer Fehler.

Der Unterschied zwischen einem generierten Befund und einem bestätigten Fehler ist zentral für die neue Richtlinie. Ein Modell kann einen Pfad durch den Code vorschlagen, aber die Maintainer müssen ihn reproduzieren, feststellen, ob ein Angreifer ihn erreichen kann, und bestimmen, welche Releases betroffen sind. Ein Befund in einer Testumgebung ist möglicherweise nicht in der Produktion vorhanden; eine fehlende Prüfung in einem Codezweig kann anderswo eine kompensierende Kontrolle haben. Die Schwere erfordert die Untersuchung realer Vorbedingungen und Konsequenzen. Die Einstufung als schnelle Offenlegung erfolgt nach dieser technischen Arbeit, nicht wenn ein KI-Tool eine plausible Erklärung ausgibt.

Das Projekt-Repository beschreibt Code-Review und Tests als Engpässe für die Entwicklung. Eine Flut minderwertiger Berichte könnte dieselbe knappe Aufmerksamkeit verbrauchen, die zur Behebung eines ernsten Problems benötigt wird. Umgekehrt kann ein glaubwürdiger, reproduzierbarer Bericht den Maintainern eine frühere Warnung geben. Die Sicherheitsmelde-Anweisungen von Bitcoin Core leiten sensible Befunde an ihre Sicherheits-E-Mail-Adresse statt an ein öffentliches Issue. Das Update macht es nicht zur guten Praxis, unbestätigte Exploit-Details offen zu veröffentlichen, während die Maintainer sie noch prüfen.

Bitcoin-Sicherheitsgruppen forderten im August Zugang zu Frontier-KI, um defensive Arbeit zu unterstützen. Die separate Richtlinienänderung von Bitcoin Core befasst sich mit Fehlern, die andere Nutzer derselben Tools möglicherweise wiederentdecken. Poinsot sagte, die Maintainer hätten mehr solcher Berichte erhalten und seien zu dem Schluss gekommen, dass das Zurückhalten eines Fixes in diesen Fällen wenig Schutz bot.

Die vier Schweregrad-Beispiele der Sicherheitsrichtlinie zeigen, warum eine einzige Warnung nicht für jeden Node passen kann. Ein remote ausgelöster Absturz unter Standardeinstellungen kann einen öffentlich verbundenen Dienst stören. Ein Fehler, der eine spezielle, in einem lokalen Netzwerk aktivierte Funktion erfordert, betrifft eine kleinere Gruppe. Ein Problem bei der Erstellung von Blockvorlagen kann für einen Miner dringend sein, ohne dieselbe sofortige Maßnahme für einen Händler zu erzeugen, dessen Node nur eingehende Blöcke verifiziert. In jedem Fall misst „leicht wiederzuentdecken“, wie leicht ein Angreifer über die Schwachstelle erfahren kann, nicht, welche Betreiber die betroffene Konfiguration haben. Der Advisory muss beide Informationen enthalten, wenn der neue Zeitplan nützlich sein soll.

Die historische Advisory-Liste von Bitcoin Core enthält Denial-of-Service-Bedingungen, die die Blockverbreitung verlangsamen, den Speicher erschöpfen oder einen Node zum Absturz bringen, neben einem früheren Inflationsfehler, der den Konsens bedrohte. Dies sind keine austauschbaren Vorfallklassen. Die Richtlinie schließt kritische Fehler ausdrücklich vom Standardzeitplan aus und bewahrt so Raum für eine Reaktion, die auf das Risiko für das gesamte Netzwerk zugeschnitten ist. Der neue Weg der leichten Entdeckbarkeit sollte daher als zusätzliche Offenlegungsentscheidung innerhalb des Sicherheitsprozesses des Projekts gelesen werden, nicht als Behauptung, dass KI die Konsensregeln von Bitcoin verändert hat.

Entwickler waren sich über die Warnung selbst uneinig

Die Richtliniendiskussion enthält einen erheblichen Einwand gegen gleichzeitige Veröffentlichung und öffentliche Warnung. Der Bitcoin-Entwickler Antoine Riard argumentierte im Pull Request, dass ein Advisory eine unnötige überstürzte Migration bei Nutzern auslösen könnte, die von dem jeweiligen Fehler nicht betroffen sind. Sein Beispiel unterschied ein Blockvorlagen-Problem, das Miner dringend adressieren müssten, von einem Fall, in dem Händler einen sorgfältigeren Upgrade-Pfad wählen könnten. Ein undifferenzierter Sicherheitsalarm kann jeden Betreiber das Gefühl geben, dass er Produktionssysteme sofort ändern muss.

Riard bestritt nicht, dass einige Fehler leicht zu entdecken sind. Er stellte den Zeitpunkt und den Inhalt einer Warnung in Frage, die an Betreiber mit unterschiedlichem Risikoniveau gesendet wird. Eine schnelle Veröffentlichung könnte Minern, Händlern, Wallets und Börsen gleichzeitig einen gepatchten Branch geben, während ein Advisory die unterschiedliche Exposition für jede Gruppe erklärt. Wenn das Advisory zu vage ist, erkennen betroffene Betreiber möglicherweise nicht ihre Dringlichkeit; wenn es zu breit ist, könnten nicht betroffene disruptive Maßnahmen ergreifen. Die endgültige Richtlinie behielt das Versprechen eines Advisorys neben den Point-Releases bei und legte keine einzige Vorlage für die Beschreibung jeder betroffenen Rolle fest.

Poinsots Gegenargument ist, dass längere Geheimhaltung unterstützte ältere Branches daran hindern kann, einen Fix zu erhalten, und ein leicht auffindbarer Fehler wahrscheinlich nicht verborgen bleibt, nur weil das Projekt wartet. Beide Positionen akzeptieren, dass die Bereitstellung langsam ist und eine öffentliche Mitteilung Verhalten bewegen kann. Sie unterscheiden sich darin, welches Risiko für einen bestimmten bestätigten Fehler dominiert. Die Richtlinie macht „leicht zu entdecken“ zu einem Triage-Urteil und überlässt es den Maintainern, den schnellen Weg nur dann zu wählen, wenn sie der Meinung sind, dass die Verzögerung des Patches schwerer zu rechtfertigen ist als das Offenlegungsrisiko.

Keines der Argumente belegt, dass eine Veröffentlichung immer harmlos ist oder dass Geheimhaltung immer Menschen schützt. Ein sehr einfacher Fehler, der einen Standardnetzwerkdienst betrifft, könnte Geschwindigkeit paramount machen. Ein Fehler, der ein enges, nicht standardmäßiges Setup betrifft, könnte hochspezifische Anweisungen verdienen, selbst wenn ein Modell ihn leicht beschreiben kann. Die Schweregradkategorien und die neue Entdeckungsbewertung sollten zusammen die Versionshinweise prägen. Bitcoin Core hat keine Liste zukünftiger Fälle veröffentlicht, und kein Zwischenfall nach der Änderung belegt bisher, wie gut der Ansatz in der Praxis funktioniert.

Core Lightning bietet ein anderes Betriebsbeispiel

Die Richtlinie von Bitcoin Core regelt Bitcoin Core, nicht jedes Programm im Bitcoin-Ökosystem. Die Core-Lightning-Entwickler sahen sich im August mit ihrem eigenen Volumen an KI-generierten Berichten konfrontiert und bestätigten, dass mehrere Einsendungen reale Schwachstellen beschrieben. Im Oktober warnte das Team Betreiber älterer Nodes, nachdem Berichte über Angriffe auf Systeme mit Version 26.06.7 oder älter eingegangen waren. Es drängte auf ein Upgrade auf eine neuere Version. Das Team hatte die Angriffsmethode in dieser Warnung nicht öffentlich identifiziert oder Nutzerverluste bestätigt, daher sollten die Berichte nicht als Beweis für einen bestimmten Exploit behandelt oder auf den Code von Bitcoin Core übertragen werden.

Das Lightning-Beispiel zeigt, warum ein verfügbarer Fix die Sicherheitsreaktion nicht abschließt. Betreiber verwenden möglicherweise weiterhin ältere Software, nachdem gepatchte Releases existieren. Die Quelle von 26.06.7 im August wurde zunächst zwei Wochen zurückgehalten, damit Betreiber das Release installieren konnten, bevor potenzielle Angreifer die Änderungen studierten; die spätere Veröffentlichung der Quelle und die Oktober-Warnung folgten einer anderen Offenlegungssequenz als der neue Easy-Discovery-Weg von Bitcoin Core. Die Software, die Netzwerkschicht und die Bedrohung waren unterschiedlich. Die gemeinsame praktische Tatsache ist, dass eine Mitteilung ein System nur schützt, wenn der zuständige Betreiber sie versteht und das richtige Update bereitstellt.

Einigen Lightning-Node-Betreibern wurde gesagt, dass der Offline-Betrieb eines Daemons die Exposition vorübergehend begrenzen könnte, während er weiterhin die Blockchain überwacht. Ein Bitcoin-Core-Betreiber sollte diese Anweisung nicht übernehmen, ohne die Anforderungen seiner eigenen Anwendung zu prüfen. Eine Full Node, die von einer Wallet, einer Börse oder einem Lightning-Dienst genutzt wird, kann Verpflichtungen haben, die auch bei Änderungen der Netzwerkkonnektivität fortbestehen. Die Bitcoin-Core-Mitteilung zu einer bestimmten Schwachstelle muss angeben, ob eine vorübergehende Konfigurationsänderung nützlich ist. In der Richtlinie vom 22. Oktober erscheint keine pauschale Problemumgehung.

Der Unterschied zwischen „verfügbar“ und „installiert“ ist am leichtesten zu erkennen, wenn eine Schwachstelle nicht jede Konfiguration betrifft. Ein Miner kann einen Block-Template-Dienst neben seiner validierenden Node betreiben. Eine Verwahrplattform kann ihren Bitcoin-Core-Prozess vom öffentlichen Internet isolieren, aber internen Programmen erlauben, ihre RPC-Schnittstelle aufzurufen. Ein Heimanwender kann die Standardnetzwerkeinstellungen mit einer integrierten Wallet verwenden. Ein Point-Release kann alle drei Bereitstellungen beheben, doch die unmittelbare Exposition und die zum Testen eines Updates erforderliche Zeit können sich unterscheiden. Die öffentliche Richtlinie von Bitcoin Core versucht nicht, diesen Betreibern eine einheitliche Frist zuzuweisen.

Eine gut abgegrenzte Mitteilung könnte die betroffenen Versionen und Einstellungen, den Schaden, den ein erfolgreicher Exploit verursachen könnte, und ob der Angriff Netzwerkzugriff, lokalen Zugriff oder eine bestimmte Nutzeraktion erfordert, angeben. Das Projekt hat diese Unterscheidungen in früheren Mitteilungskategorien verwendet. Betreiber können dann ihre eigenen Konfigurationen mit den beschriebenen Bedingungen vergleichen. Die Änderung vom 22. Oktober verspricht, eine Mitteilung mit einem Fix für die Easy-Discovery-Gruppe zu veröffentlichen, aber die genauen offengelegten Fakten werden vom ersten verifizierten Problem abhängen, das so eingestuft wird.

Die erste schnelle Offenlegung wird das Tempo festlegen

Die schriftliche Änderung gibt den Maintainern einen neuen Weg, liefert aber noch keine Fallstudie. Die messbare Abfolge beginnt mit einem verifizierten Bericht und einer Klassifizierung, geht über zu Patches für alle drei gepflegten Branches und endet mit signierten Point-Releases und einer Mitteilung. Daten zu diesen Schritten würden zeigen, wie schnell das Projekt einen Fix zurückportieren kann und ob seine öffentliche Mitteilung erst erscheint, wenn jeder Branch bereit ist. Ein Release, das zwei von drei gepflegten Linien abdeckt, würde nicht dem veröffentlichten Versprechen für die neue Kategorie entsprechen.

Die Übernahme durch die Betreiber ist schwerer zu beobachten. Öffentlich erreichbare Nodes können Softwareversionen bekanntgeben, aber Netzwerk-Crawls sehen nur eine Teilmenge der Bereitstellungen, und Versionsstrings müssen nicht jeden privaten Dienst offenlegen. Börsen und Verwahrer verwenden möglicherweise interne Nodes, die nie eingehende öffentliche Verbindungen annehmen. Ein Forscher, der einen Prozentsatz an Upgrades meldet, sollte die Stichprobe und ihre blinden Flecken erläutern. Ohne dies könnte die Zahl den Anteil der Produktionsinfrastruktur, der noch exponiert ist, untertreiben oder ihn durch Zählung ruhender öffentlicher Nodes übertreiben.

Die Versionshinweise zu 32.0 verweisen Betreiber auf die Ankündigungsliste des Projekts für Sicherheits- und Update-Benachrichtigungen. Seine Lifecycle-Seite empfiehlt das neueste Wartungsrelease des neuesten Hauptzweigs, den ein Betreiber verwenden kann. Die nächste Embargo-Offenlegung wird zwei Wochen nach der Veröffentlichung von 32.0 erwartet und drei mittelschwere oder hohe Schwachstellen beschreiben, die bereits in 30.0 behoben wurden.

Worauf zu achten ist

• Erster eingestufter Fall: Ein Advisory, das eine leicht auffindbare Schwachstelle, ihre betroffenen Versionen und die Grundlage für die schnelle Veröffentlichung benennt.
• Drei Point-Releases: Entsprechende Fixes für 30.x, 31.x und 32.x oder eine aktualisierte Wartungsgrenze, falls eine neue Hauptversion erscheint.
• Details im Advisory: Klare Unterscheidungen zwischen Minern, Händlern, Verwahrern und Heimknoten, wenn ihre tatsächliche Exposition abweicht.
• Übernahme durch Betreiber: Datierte Versionsmessungen mit ausdrücklicher Stichprobe, zusammen mit Offenlegungen von Diensten, die private Knoten betreiben.
• Ausstehende alte Fälle: Die drei Fixes mittlerer oder hoher Schwere aus 30.0, die laut den Versionshinweisen von 32.0 nach der üblichen Verzögerung erläutert werden sollen.

FAQ