К обсуждениям

Crossplane xpkg: проверка TOCTOU между verify и fetch

Редакция VOne Технологии

Защитная диагностика Crossplane по GHSA-mf7q-r4rv-jv94: version inventory, обратимый fixture, PASS/FAIL/Unknown, stop-rule и минимальный пакет доказательств без production-данных.

Что именно проверяет карточка Crossplane

Здесь не проводится общий аудит продукта и не пересказывается чужая публикация. Проверяется одна граница: mutable tag может указывать на другой image после проверки подписи и до фактической загрузки. Advisory GHSA-mf7q-r4rv-jv94 формулирует upstream-сигнал как «Crossplane's TOCTOU between cosign verification and image fetch in xpkg.CachedClient allows tag-based package install to bypass signature check» и задаёт version inventory «github.com/crossplane/crossplane-runtime/v2: = 2.4.0-rc.0; первая исправленная версия: 2.4.0-rc.1». Само совпадение версии означает только affected_candidate. Оно не подтверждает достижимость пути, наличие инцидента или ущерба. Для not_present нужен runtime/SBOM, для outside_range — resolved dependency, для patched_or_backported — release либо commit и повторяемый regression result. Если связать работающий artifact с revision нельзя, честный ответ — Unknown. Уникальная модель наблюдения для этой карточки связывает гарантию «после verify установка должна использовать тот же immutable digest, а не повторно разрешать tag» с действием «локальный fake registry меняет mapping тестового tag между фазами; fixture подписывает только первый пустой artifact». Она считается полной только вместе с колонками «verified digest | fetched digest | tag changed | install decision | verdict» и отдельным аварийным условием «установлен иной digest, отправлен запрос во внешний registry или в лог попал закрытый ключ». Эти пять элементов образуют самостоятельную проверку именно Crossplane, а не заменяемый шаблон для соседнего продукта.

Дерево решения по версии и функции Crossplane

Соберите package manager, lock-файл, digest образа или бинарника, feature flag и фактическую точку вызова. Сначала установите, присутствует ли github.com/crossplane/crossplane-runtime/v2 в runtime, а не только в исходном manifest. Затем сравните доказанную версию с границей «github.com/crossplane/crossplane-runtime/v2: = 2.4.0-rc.0; первая исправленная версия: 2.4.0-rc.1». Ветка not_present завершает проверку без запуска fixture; outside_range требует сохранённого вывода inventory; affected_candidate переходит к изолированному тесту; patched_or_backported требует ссылки на исправление и его test evidence. Не подменяйте эти состояния одним HTTP 200, названием контейнера, датой сборки или отсутствием жалоб.

Обратимый fixture для механизма GHSA-mf7q-r4rv-jv94

Целевая гарантия сформулирована так: после verify установка должна использовать тот же immutable digest, а не повторно разрешать tag. Проверка: локальный fake registry меняет mapping тестового tag между фазами; fixture подписывает только первый пустой artifact. Среда должна быть одноразовой, без production snapshot, персональных данных, токенов и открытого исходящего доступа. До boundary-case выполните benign control, чтобы доказать достижимость нужной ветки. Заранее установите таймаут, лимит CPU/RSS, разрешённое дерево temp и сетевой allowlist loopback. После каждого шага прочитайте состояние обратно и удалите созданные объекты. Не используйте опубликованные exploit payload или реальные идентификаторы.

Как заполнить таблицу «verified digest | fetched digest | tag changed | install decision | verdict»

Записывайте по одной строке на benign control и boundary-case: verified digest | fetched digest | tag changed | install decision | verdict. PASS означает, что control дошёл до нужной функции, граничный случай был управляемо отклонён, состояние и side effects не изменились. FAIL допустим только при работающем control и наблюдаемом нарушении заявленной гарантии. Unknown обязателен при недоказанной версии, недостижимой ветке, неполной телеметрии, раннем срабатывании limiter или неоднозначном readback. Такая матрица отделяет наблюдение от догадки и позволяет другому инженеру повторить проверку без доступа к исходной среде.

Исправление и безопасная последовательность rollout

Если получен affected_candidate или воспроизводимый FAIL, выберите поддерживаемую upstream-ветку с исправлением; ориентир inventory: github.com/crossplane/crossplane-runtime/v2: = 2.4.0-rc.0; первая исправленная версия: 2.4.0-rc.1. Сначала сохраните lock/digest и fixture, затем измените только компонент, повторите benign и boundary cases, проверьте readback и лишь потом переходите к canary. Не смешивайте обновление с заменой proxy, прав, storage и формата данных: это разрушает причинность. Защитный фильтр может быть временной мерой, но не заменяет исправление. Stop-rule этого материала: установлен иной digest, отправлен запрос во внешний registry или в лог попал закрытый ключ. При его срабатывании тест немедленно прекращается, артефакты изолируются, production не меняется.

Пакет доказательств для владельца Crossplane

В handoff включите GHSA-mf7q-r4rv-jv94, границу «github.com/crossplane/crossplane-runtime/v2: = 2.4.0-rc.0; первая исправленная версия: 2.4.0-rc.1», artifact digest, source revision, feature state, hash fixture, лимиты, результаты control и boundary-case, одну строку из таблицы «verified digest | fetched digest | tag changed | install decision | verdict», итог PASS/FAIL/Unknown и точную причину Unknown. Добавьте ссылки на GitHub Advisory Database и upstream advisory/fix, но не копируйте длинные фрагменты. Отдельной строкой укажите, что проверялась боль «mutable tag может указывать на другой image после проверки подписи и до фактической загрузки», а не весь продукт. Уберите hostname, IP, usernames, cookies, tokens, конфиги и содержимое пользовательских объектов. Так evidence остаётся минимальным, проверяемым и пригодным для повторного решения. Для машиночитаемого журнала используйте независимые ключи `crossplane-xpkg-tag-verification-fetch-check-inventory-proof`, `crossplane-xpkg-tag-verification-fetch-check-benign-control`, `crossplane-xpkg-tag-verification-fetch-check-boundary-observation`, `crossplane-xpkg-tag-verification-fetch-check-state-readback`, `crossplane-xpkg-tag-verification-fetch-check-sideeffect-diff`, `crossplane-xpkg-tag-verification-fetch-check-stop-trigger`, `crossplane-xpkg-tag-verification-fetch-check-final-verdict` и `crossplane-xpkg-tag-verification-fetch-check-cleanup-proof`. Они не должны содержать значения секретов; это только имена полей, позволяющие не спутать доказательства этой проверки с соседними карточками.

Материал подготовлен редакцией VOne с помощью ИИ; даты, версии, первичные источники, обратимый fixture, stop-rule, privacy-ограничения и отсутствие рекламных обещаний перепроверены человеком.

Источники и проверка

Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.

Ответы

0 опубликовано
Ответов пока нет. Вы можете начать обсуждение.

Ваш ответ

Добавьте свой опыт или уточнение по теме.

Вы публикуете как Аноним Аватар отличает разговоры, но не раскрывает личные данные.

Ответ появится сразу. Не публикуйте личные данные, ключи и приватные ссылки.