Bitcoin Core завершує річний заборону на легко виявляні помилки

Bitcoin Core завершує річне очікування на виправлення безпеки, які мовна модель може знову знайти за один запит. Зміна в політиці розкриття безпеки проекту, об’єднана 22 жовтня, створює клас уразливостей, які легко виявити, і доручає супроводжувачам випустити точкове оновлення та публічне повідомлення «як можно швидше» — обходячи стандартну ембарго, яка тримає середню або високу за важливістю помилку в таємниці приблизно рік.

Тригер є грубим. Супроводжувачі отримують більше повідомлень про баги, які постійно відкриваються знову, оскільки мовні моделі зменшили зусилля, необхідне для їх знаходження. Антуан Пуансот, учасник Bitcoin Core у Chaincode Labs, оголосив про цю зміну у списку розсилки Bitcoin Development того ж дня, коли було об’єднано запит на внесення змін.

«Ми недавно зафіксували зростання кількості повідомлень про безпекові уразливості, які можна легко (пере)виявити», — написав Пуансот. «Це в основному пов’язано з тим, що ВМН значно знизили бар’єр для виявлення певних класів проблем або виявлення прихованих виправлень.»

Попередня політика Bitcoin Core зв’язувала час розголошення зі ступенем серйозності. Низькоступеневі вразливості публікувалися через два тижні після виходу наступного основного випуску. Вразливості середньої та високої серйозності залишалися конфіденційними до двох тижнів після завершення підтримки останнього вплинувого випуску — період, який сама політика описує як «приблизно рік після того, як основна версія з виправленням була вперше випущена».

Цей розклад існував з певною метою. Bitcoin Core — це еталонна реалізація, яка працює на більшості нод Bitcoin, і оператори нод оновлюються повільно. Довгий період нерозголошення був призначений, щоб надати мережі час на застосування виправлень до публікації деталей. Компромісом було те, що виправлення зазвичай не переносилися назад, тому оператор на старішій версії чекав на наступну основну версію, яку проект планує випускати приблизно кожні шість місяців.

Попередження носить структурний, а не випадковий характер. Зміни консенсусу, такі як апгрейд Taproot bitcoin, проходять повільним, обережним шляхом саме для того, щоб оператори могли впроваджувати їх у власний графік.

«З урахуванням природи нашого проекту та повільної культури оновлень, наша політика безпеки передбачає довший період конфіденційності», — написав Пуансот. «Це, як правило, означає, що виправлення безпеки не можуть бути зворотно застосовані і стають доступними для користувачів лише разом із наступним великим випуском».

AI ламає цей компроміс. Якщо помилку можна виявити за допомогою простого сканування LLM, приховування її нічого не дає, оскільки цей недолік вже доступний будь-кому, хто має чат-бота. «Щодо цих проблем, які легко знайти, це неправильний компроміс. Період ембарго майже нічого не досягає, але затримує доступність виправленого випуску», — написав Пуансот.

За оновленою політикою, таймер розкриття тепер має третій режим. Під час класифікації вразливість може бути позначена як «легко виявляєма» — визначається як така, «яку можна виявити з мінімальними зусиллями, наприклад, за допомогою простого запиту до LLM». Ця позначка не обмежується лише помилками, знайденими штучним інтелектом: вона вказує на те, наскільки мало зусиль потрібно для повторного виявлення, а не на те, який інструмент зробив знаходження.

Щодо цих помилок, відповідь змінюється на кожній осі. Замість того, щоб один виправлення потрапило у наступний основний реліз, супроводжуючі зроблять бекпорт виправлення до кожного поточно підтримуваного основного релізу — трьох гілок за правилом Bitcoin Core щодо підтримки трьох останніх релізів — і випустять точкові релізи найшвидше, наскільки це можливо. Оголошення про безпеку публікується разом із виправленою програмою.

Драбинка серйозності все ще керує всім іншим. Помилки низької серйозності залишаються на двотижневому графіку. Помилки середньої та високої серйозності залишаються на приблизно річному терміні. Критичні помилки — ті, що можуть вкрасти монети на рівні протоколу, збільшити пропозицію або назавжди розділити ланцюг — залишаються поза стандартною політикою і розглядаються в окремих випадках, як і раніше.

Це виняток існує з доброї причини. У історії Bitcoin Core вразливість, виявлену як CVE-2018-17144 у вересні 2018 року, була тим типом недоліку, що виправдовував спеціальний підхід: вона могла дозволити створення монет поза графіком емісії. Новий шлях, який «легко виявити», не стосується цього рівня — критична вразливість все ще отримає ад-хок відповідь, спрямовану на мінімізацію ризику для всієї мережі.

Зміну найлегше сприйняти як згортання у вікні розкриття. Помилка середньої важливості, виправлена сьогодні, зазвичай залишатиметься конфіденційною протягом приблизно 52 тижнів і розкриватиметься лише через два тижні після того, як останній впливаний реліз досягне кінця життєвого циклу. Та сама помилка, якщо її визначено як легко виявляєму, видається у вигляді точкового релізу «якнайшвидше» разом із повідомленням про неї. Ось різниця між роком і, у власному формулюванні розробників, тим часом, який потрібен для написання, перевірки та тестування цільового патчу.

Зобов’язання щодо зворотного перенесення — це інша половина. До зміни виправлення зазвичай не досягало користувачів на старій підтримуваній гілці; воно надходило разом із наступним основним випуском. Зараз оператор на старій підтримуваній версії може застосувати цільовий точковий випуск, не приймаючи всі функції та зміни поведінки в найновішій основній версії. Для мережі, де оновлення є повільними та обережними, це суттєва зміна швидкості, з якою виправлення може бути реально застосоване.

Швидший шлях має вартість, і Пуансе чітко сказав це у запиті на витяг. «Це особливо важливо, оскільки за цією політикою засоби зменшення ризиків матимуть менше «часу витримки» у розробницьких гілках перед тим, як їх буде випущено користувачам», — написав він. Виправлення, яке виходить через кілька днів, проводить менше часу на перевірку та тестування, ніж теж, що чекало місяцями.

Обговорення також розділилося щодо того, чи слід прискорити розкриття інформації. Деякі учасники вважали, що відкриття запиту на виправлення може саме по собі попередити зловмисників, оскільки стежити за репозиторієм автоматично — це дуже дешево, тому розкриття може бути не пізніше за виправлення або навіть раніше, разом із рекомендаціями щодо зменшення ризиків. Інший учасник запропонував впроваджувати виправлення разом із добровільним або запізненим повідомленням. Поансот відхилив цю пропозицію, написавши, що попередження користувачів без деталей може спричинити поспішну міграцію серед операторів, які ніколи не страждали.

Біржа має значення, бо показує, що нова політика — це обдуманий середній шлях, а не очевидний. Об’єднаний текст зберігає консультацію одночасно з виправленням і повну інформацію, а не загальну попередження.

У новий клас ще не додано жодної вразливості, тому це зміна процесу, а не розголошення активної помилки. Перший справжній тест настане, коли супроводжувачі під час класифікації позначать щось як «легко виявляєме» і випустять точкові оновлення для всіх підтримуваних гілок разом із одночасним повідомленням.

Більш широкий сигнал полягає в тому, що використання ШІ для пошуку помилок вже змусило екосистему Bitcoin змінитися. Core Lightning ще на початку цього року повідомив операторів нод, що мають оновити або відключитися, після того як звіти про вразливості, згенеровані ШІ, виявилися правильними. Зміна політики Bitcoin Core — це реалізація зразка, що робить той самий розрахунок на базовому рівні протоколу: коли повторне виявлення дешеве, секретність дає мало, а довгий ембарго затримує лише фіксований реліз.

Для операторів нод сьогодні нічого не змінюється. Частота оновлень залишається такою самою. Різниця виникає наступного разу, коли баг вважатиметься легко виявляємим, і патч разом із повідомленням про нього буде випущений з меншим терміном сповіщення, ніж коли-небудь раніше мав мережа.