Bitcoin Core Herziet Openbaarmakingsbeleid nu AI Bugs Makkelijker Vindbaar Maakt
Belangrijkste punten
- •Bitcoin Core heeft de ernstgebaseerde embargoperiode voor eenvoudig vindbare bugs geschrapt; ontwikkelaar Antoine Poinsot zette de beleidswijziging op 22 oktober in het beveiligingsbeleid van het project.
- •De ontwikkelaars noemden taalmodellen als belangrijke drijfveer, omdat ze bepaalde bugcategorieën kunnen blootleggen én verborgen beveiligingspatches zonder label in de openbare code kunnen herkennen.
- •Volgens de herziene regel kunnen details van gemakkelijk vindbare kwetsbaarheden samen met de gerepareerde release worden gepubliceerd in plaats van na een wachtperiode.
- •Nodes die Bitcoin Core 28.x of ouder draaien ontvangen deze fixes doorgaans niet, en de komende release 32.0 zal 29.x uit het onderhoudsvenster duwen.
- •De update is uitsluitend een wijziging van het openbaarmakingsbeleid en meldt geen nieuwe exploit; het raakt niets aan de cryptografie van Bitcoin of de veiligheid van de privésleutels van gebruikers.

Bitcoin Core heeft zijn beleid voor de openbaarmaking van kwetsbaarheden herzien, waarbij de ernstgebaseerde embargoperiode voor eenvoudig vindbare bugs komt te vervallen — waaronder problemen die naar voren kunnen komen uit een eenvoudige prompt aan een taalmodel. Ontwikkelaar Antoine Poinsot zette de wijziging in het beveiligingsbeleid op 22 oktober van het project.
De update is een openbaarmakingsregel, geen rapport over een nieuwe exploit, en zegt niets over de cryptografie van Bitcoin of de veiligheid van de privésleutels van gebruikers.
Waarom AI de Embargo Ondermijnde
De ontwikkelaars schreven dat ze onlangs meer meldingen zagen van kwetsbaarheden die gemakkelijk gevonden kunnen worden, of opnieuw gevonden. Ze schreven dit grotendeels toe aan taalmodellen, die de drempel verlagen voor het opsporen van bepaalde bugcategorieën en tevens verborgen fixes kunnen identificeren: beveiligingspatches die zonder label in de code zijn samengevoegd.
Dat tweede punt ondermijnt het doel van een embargo: de periode waarin beheerders de details van een gemelde fout inhouden terwijl een gerepareerde release wordt voorbereid. Bitcoin Core is open source, dus een fix is lang zichtbaar in de publieke code voordat de details worden gepubliceerd. Als een model een wijziging kan herkennen als beveiligingsfix, helpt zwijgen weinig om de bug voor aanvallers te verbergen, terwijl het een gerepareerde release voor gebruikers nog steeds vertraagt.
"De embargoperiode levert weinig op, maar vertraagt de beschikbaarheid van een gerepareerde release", schreven de ontwikkelaars.
Lange embargo's bepaalden ook waar fixes terechtkwamen. De ontwikkelaars merkten op dat hun aanpak er doorgaans toe leidde dat beveiligingsfixes niet konden worden teruggepoetst — teruggevoerd naar oud, nog ondersteunde versies — en dat gebruikers ze pas met de volgende grote release bereikten.
Hoe de Nieuwe Regel de Tijdlijn Verandert
De bestaande tijdlijnen, uiteengezet op de beveiligingsadviespagina van het project, tonen hoe lang die wachttijd kan zijn. Ontwikkelaars bepalen de classificatie bij het beoordelen van een melding.
Van de nieuwe regel wordt verwacht dat deze bugs omvat die met minimale inspanning gevonden kunnen worden, bijvoorbeeld via een eenvoudige prompt aan een taalmodel, hoewel deze niet beperkt is tot AI-ontdekkingen. Voor deze bugs geldt de ernstgebaseerde embargo niet langer, en details kunnen samen met de gerepareerde release worden gepubliceerd in plaats van na een wachtperiode.
Welke Nodes de Patch Krijgen
Het onderhoudsbeleid van Bitcoin Core dekt de drie meest recente grote versies. Wanneer een nieuwe wordt uitgebracht, veroudert de oudste tot einde-levensduur en ontvangt deze doorgaans geen beveiligingsfixes meer.
Nodes die nog op 28.x of ouder draaien, ontvangen deze fixes doorgaans niet. Het project streeft naar een grote release elke zes tot zeven maanden, en de volgende, 32.0, zal 29.x uit het onderhoudsvenster duwen. Bitcoin Core raadt aan de nieuwste onderhoudsrelease van de meest recente versie te draaien waarnaar een operator kan upgraden, en de downloadpagina legt uit hoe release-controlesommen en handtekeningen geverifieerd kunnen worden.
Backporten hangt ook af van mensen. De levenscycluspagina van het project merkt op dat de drempel voor het terugpoetsen van een wijziging stijgt naarmate een versie ouder wordt, en dat er niet altijd genoeg vrijwilligers zijn om dit te beheren. Onderhoudscapaciteit heeft ook andere beslissingen bepaald, zoals bleek uit het eerdere debat over de ondersteuning door Bitcoin Core van het CJDNS privacynetwerk.
De Afweging, en Waar je op Moet Letten
De ontwikkelaars beschouwen elk beveiligingsbeleid als een balans tussen transparantie, die zowel aanvallers als verdedigers helpt, en gebruikers tijd geven om te upgraden — iets wat de trage upgradecultuur van Bitcoin Core bemoeilijkt. Het publiceren van een advies naast de gerepareerde releases betekent dat details openbaar worden terwijl sommige nodes nog ongepatchte software draaien. Voor bugs die aanvallers zelf zouden kunnen vinden, vinden de ontwikkelaars dat een snelle fix zwaarder weegt dan het geheimhouden van de details.
Het eerste beveiligingsadvies dat onder de nieuwe regel wordt uitgege, zal tonen hoe snel point-releases — kleine updates binnen een grote versie — in de praktijk alle drie de onderhouden versies bereiken. Apart daarvan zal de release van 32.0 de groep nodes die ze kunnen ontvangen verkleinen.
Dit artikel is uitsluitend bedoeld voor informatieve doeleinden en vormt geen financieel of beleggingsadvies. Node-operators dienen de officiële release-opmerkingen en verificatie-instructies van Bitcoin Core te volgen.
Bron: Coindoo