Кратко

  • Руководство LACNIC от 10 августа скачивает fort-1.7.0.experimental.tar.gz для Ubuntu Server 26.04, распаковывает, собирает и запускает sudo make install, не проверяя checksum или отделённую подпись.
  • В release уже находились tarball, .asc и fort.keyring. Захваченные 31 августа файлы совпадают с текущими SHA-256 в API; GnuPG возвращает GOODSIG и VALIDSIG для fingerprint 8F9ABC7EF3BA565F9DF1578C72160FD57B242967.
  • Это сильное подтверждение захваченной пары «файл–подпись», но не полное решение о доверии: та же изолированная проверка показывает TRUST_UNDEFINED, а API в момент наблюдения помечал release как не immutable.
  • Для настоящего rollback надо сохранить tag и commit, asset и digest, независимый источник fingerprint, входы сборки, hash установленного binary, время активации и идентичность предыдущей версии.

Откат начинается не после сбоя, а до установки

Операционные инструкции часто оставляют rollback на конец: если новая версия не заработает, вернитесь к старой. Но команда возврата имеет смысл только при двух условиях. Новая и старая версии должны быть идентифицированы точнее строки версии, а переход между ними — записан.

Руководство LACNIC описывает FORT 1.7.0.experimental на Ubuntu Server 26.04 для amd64/x86_64. По результатам его теста пакет .deb запрашивал libmicrohttpd12 и libxml2, тогда как система предоставляла пакеты с другими именами. Поэтому выбран путь сборки с нативными development libraries. Данная проверка не воспроизводила проблему .deb самостоятельно и не расширяет утверждение за пределы опыта автора документа.

Далее оператор скачивает tarball, выполняет tar -xzf, ./configure, make -j"$(nproc)" и sudo make install. После установки следуют fort --version, ldd, первая validation, просмотр output, настройка service и RTR, проверка синхронизации часов.

Это полезные признаки того, что полученный результат запускается. Они не отвечают на вопрос, какие bytes были распакованы. В PDF нет SHA-256, checksum, .asc, keyring или команды проверки подписи. Упоминание подписи относится к подписанным объектам RPKI, а не к загруженному software. Зафиксированный на release commit файл upstream installation также скачивает и устанавливает package или source archive без digest и detached-signature verification.

Если через полгода потребуется объяснить, какой исполняемый файл формировал результаты validation, одной строки 1.7.0.experimental будет недостаточно.

Текущая проверка архива дала положительный результат

GitHub датирует создание 1.7.0.experimental 16 июля 2026 года, 01:52:42Z, а публикацию — 03:45:33Z. Annotated tag указывает на commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e; API tag object сообщает valid и verified signature.

Tarball был добавлен в 03:47:16Z, отделённая подпись — в 03:47:19Z, fort.keyring — в 03:51:35Z. Все три объекта существовали до публикации руководства 10 августа.

При наблюдении 31 августа API показывал:

Объект SHA-256
fort-1.7.0.experimental.tar.gz 70075f82effe5cf9752b13463f50c4379fdf93e5c28bdf6cba04e9621e2288cc
.asc e648b9ff2075c6d78f4bf1a69c96a5b421757432b71f916a3118fb11ffe815ad
fort.keyring 8e4dfee468ad756bc89ffff3894692e87e66ffbd135dc697f3ffbac02116e6a6

Независимо полученные bytes соответствуют всем трём текущим значениям. После импорта предоставленного keyring проверка .asc относительно tarball возвращает GOODSIG и VALIDSIG. Полный основной fingerprint — 8F9ABC7EF3BA565F9DF1578C72160FD57B242967; timestamp подписи — 16 июля, 01:55:02Z.

Это необходимо сформулировать как сильную защиту release. Исследованные данные не показывают вредоносный, подменённый или неверный архив. Захваченный tarball совпадает с текущим digest API, а его detached signature математически действительна под предоставленным public key. Нет данных о сбое RPKI validation или routing incident.

Одновременно GnuPG сообщает TRUST_UNDEFINED и предупреждает, что ключ не был сертифицирован доверенной подписью во временной среде. Это не отменяет VALIDSIG. Математическая связь с private key подтверждена; личность владельца и его полномочие подписывать FORT не установлены независимо. Для этого нужен fingerprint из аутентифицированного внешнего канала и правила rotation/revocation.

Версия, asset и binary стареют по-разному

Подписанный tag соединяет имя с commit c67d14b…. Он не распространяет подпись автоматически на загруженный отдельно release asset.

Запись release соединяет asset name с текущим digest и timestamps. В момент наблюдения API также возвращал immutable: false, draft: false, prerelease: false. Не immutable не значит изменён. Это значит, что hash и состояние надо фиксировать с датой, а не считать сегодняшнее значение доказательством каждого прошлого download.

Detached signature соединяет bytes с ключом. Доверие к ключу требует независимого источника полномочий. Получение tarball, signature и keyring с одного сервиса удобно для криптографической проверки, но не создаёт независимую trust root.

Сборка соединяет source с local binary. Compiler, flags, headers и dependency versions входят в результат. ldd описывает runtime links, но не полную историю build. Материалы не заявляют bit-for-bit reproducibility, и текущая проверка её не доказывает.

Для rollback различия решающие. Можно вернуть файл с прежним названием и не вернуть прежние bytes. Можно восстановить прежний tarball, но собрать другой binary. Можно иметь тот же binary и уже иную оценку авторизации ключа после revocation. Поэтому «предыдущая версия» должна быть набором идентификаторов, а не словом.

Журнал перехода превращает возврат в контроль

До распаковки инструкция должна закрепить release URL, tag, commit и asset, сравнить ожидаемый и наблюдаемый SHA-256, получить полный fingerprint из независимого проверенного источника и проверить .asc. Любое несовпадение останавливает процедуру и создаёт запрос на исправление.

После сборки журнал сохраняет:

Этап Минимальное свидетельство
Release Tag, URL, commit, publication time, наблюдаемый immutable status
Download Filename/URL, expected и observed digest, время проверки
Signature Digests .asc и keyring, fingerprint, независимый источник, trust decision
Build OS, architecture, compiler, configure flags, dependency versions
Install Binary path и digest, version output, digests configuration и service
Activate Время, предыдущий комплект идентификаторов, rollback, key rotation/revocation, corrections

Такой журнал не назначает LACNIC владельцем всей цепочки. FORT project отвечает за release и signing identity, GitHub — за distribution surface, Ubuntu — за зависимости, оператор — за trust и routing policy. LACNIC может отвечать за точность переходов в рекомендуемой инструкции.

sudo make install — момент, когда локальная власть переходит к результату build. Команда не доказывает угрозу. Она определяет точку, после которой отсутствие digest затрудняет проверяемый возврат.

Что нельзя восстановить из публичного документа

Нельзя утверждать, что реальный оператор пропустил подпись. Он мог использовать внутренний mirror, pinned digest, утверждённый key или собственную сборочную систему. Объект анализа — опубликованная последовательность.

Нельзя считать immutable: false доказательством изменения asset. Текущий digest не доказывает каждый исторический download. Хорошая подпись под предоставленным ключом не устанавливает сама по себе юридическую личность signatory. Оснований утверждать compromise, substitution или routing impact нет.

Тема также не совпадает с FORT ASPA output и RTR negotiation. Там рассматривается выход к router. Здесь — возможность доказать происхождение executable, создавшего этот выход.

Вывод практичен: материалы для первичной проверки существовали, и текущая проверка дала положительный результат. Проблема не в обнаруженном плохом файле, а в отсутствии переносимого receipt. Добавив его, LACNIC позволит будущей команде отличить смену данных, конфигурации, зависимости, программы и ключевой политики — и выбрать осмысленный rollback.

Источники