Bitcoin Core rewizuje politykę ujawniania podatności, bo AI ułatwia znajdowanie błędów
Najważniejsze informacje
- •Bitcoin Core zniósł embargo oparte na stopniu ciężkości dla błędów łatwych do wykrycia; deweloper Antoine Poinsot wgrał zmianę polityki do polityki bezpieczeństwa projektu 22 października.
- •Deweloperzy wskazali modele językowe jako kluczowy czynnik, ponieważ potrafią zarówno wykrywać pewne klasy błędów, jak i rozpoznawać nieoznaczone poprawki bezpieczeństwa włączone do publicznego kodu.
- •Zgodnie ze zmienioną zasadą szczegóły łatwych do znalezienia podatności mogą być publikowane razem z wydaniem poprawionym, a nie po okresie oczekiwania.
- •Węzły działające na Bitcoin Core 28.x lub starszym zazwyczaj nie otrzymają tych poprawek, a nadchodzące wydanie 32.0 wypchnie 29.x z okna utrzymania.
- •Zmiana dotyczy wyłącznie polityki ujawniania — nie oznacza nowego exploitu ani nie wpływa na kryptografię Bitcoina ani bezpieczeństwo kluczy prywatnych użytkowników.

Bitcoin Core zrewidował swoją politykę ujawniania podatności, rezygnując z embarga opartego na stopniu ciężkości dla błędów łatwych do wykrycia — w tym problemów, które mogą wyjść na jaw za pomocą prostego promptu do modelu językowego. Deweloper Antoine Poinsot wgrał zmianę do polityki bezpieczeństwa projektu 22 października.
Aktualizacja to zasada dotycząca ujawniania informacji, a nie raport o nowym exploicie — nie mówi nic o kryptografii Bitcoina ani o bezpieczeństwie kluczy prywatnych użytkowników.
Dlaczego AI podważyło embargo
Deweloperzy napisali, że w ostatnim czasie otrzymywali więcej zgłoszeń podatności, które można łatwo znaleźć albo znaleźć ponownie. Przypisali to w dużej mierze modelom językowym, które obniżają próg wykrywania pewnych klas błędów, a ponadto potrafią rozpoznać ukryte poprawki — łatki bezpieczeństwa włączone do kodu bez odpowiedniego oznaczenia.
Ten drugi punkt podważa sens embarga, czyli okresu, w którym opiekunowie wstrzymują szczegóły zgłoszonej luki do czasu przygotowania wydania z poprawką. Bitcoin Core jest projektem open source, więc poprawka jest widoczna w publicznym kodzie na długo przed publikacją jej szczegółów. Jeśli model potrafi rozpoznać zmianę jako poprawkę bezpieczeństwa, milczenie niewiele daje w ukrywaniu błędu przed atakującymi, a jednocześnie opóźnia wydanie z poprawką dla użytkowników.
"Okres embarga niewiele daje, a opóźnia udostępnienie wydania z poprawką" — napisali deweloperzy.
Długie embarga wpwały także na to, gdzie trafiały poprawki. Deweloperzy zauważyli, że ich podejście oznaczało zazwyczaj, iż poprawek bezpieczeństwa nie dało się przenosić wstecz — do starszych, nadal wspieranych wersji — i docierały one do użytkowników dopiero wraz z kolejnym wydaniem głównym.
Jak nowa zasada zmienia harmonogram
Istniejące harmonogramy, opisane na stronie biuletynów bezpieczeństwa projektu, pokazują, jak długa może być taka zwłoka. Deweloperzy podejmują decyzję o klasyfikacji podczas analizy zgłoszenia.
Oczekuje się, że nowa zasada obejmie błędy możliwe do znalezienia przy minimalnym wysiłku, na przykład za pomocą prostego promptu do modelu językowego, choć nie ogranicza się do odkryć z zakresu AI. Dla tych błędów embargo oparte na stopniu ciężkości już nie obowiązuje, a szczegóły mogą zostać opublikowane razem z wydaniem poprawionym, a nie po okresie oczekiwania.
Które węzły otrzymają poprawkę
Polityka utrzymania Bitcoina Core obejmuje trzy najnowsze wersje główne. Po wydaniu nowej najstarsza przechodzi w stan end of life i zazwyczaj nie otrzymuje już poprawek bezpieczeństwa.
Węzły wciąż działające na wersji 28.x lub starszej zazwyczaj nie otrzymają tych poprawek. Projekt dąży do wydania głównej wersji co sześć do siedmiu miesięcy, a następna, 32.0, wypchnie 29.x z okna utrzymania. Bitcoin Core zaleca uruchamianie najnowszego wydania serwisowego najnowszej wersji głównej, do której operator może zaktualizować system, a strona pobierania wyjaśnia, jak zweryfikować sumy kontrolne i podpisy wydań.
Przenoszenie poprawek wstecz zależy też od ludzi. Strona cyklu życia projektu wskazuje, że próg przenoszenia zmiany wstecz rośnie wraz z wiekiem wersji, a ochotników do zajęcia się tym nie zawsze wystarcza. Moce utrzymaniowe ukształtowały także inne decyzje, co pokazała wcześniejsza debata o wsparciu Bitcoina Core dla prywatnej sieci CJDNS.
Kompromis i na co zwracać uwagę
Deweloperzy przedstawiają każdą politykę bezpieczeństwa jako równowagę między przejrzystością, która pomaga zarówno atakującym, jak i obrońcom, a dawaniem użytkownikom czasu na aktualizację — co kultura powolnych aktualizacji Bitcoina Corerudnia. Publikowanie biuletynu wraz z wydaniami poprawionymi oznacza, że szczegóły stają się publiczne, gdy część węzłów wciąż działa na niezałatanym oprogramowaniu. W przypadku błędów, które atakujący mogliby znaleźć samodzielnie, deweloperzy uznają, że szybka poprawka znaczy więcej niż zachowanie szczegółów w tajemnicy.
Pierwszy biuletyn bezpieczeństwa wydany według nowej zasady pokaże, jak szybko wydania poprawkowe — drobne aktualizacje w obrębie wersji głównej — docierają w praktyce do wszystkich trzech utrzymywanych wersji. Osobną kwestią jest to, że wydanie 32.0 zawęzi zbiór węzłów mogących je otrzymać.
Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady finansowej ani inwestycyjnej. Operatorzy węzłów powinni kierować się oficjalnymi informacjami o wydaniach Bitcoin Core oraz instrukcjami weryfikacji.
Źródło: Coindoo