Практическая проверка github.com/lxc/incus/v7 по GHSA-64f3-v33m-w89f: диапазон версий, безопасный локальный fixture, критерии PASS/FAIL/Unknown, stop-rule и пакет данных для поддержки без production-секретов.
Что именно проверить в github.com/lxc/incus/v7
Для github.com/lxc/incus/v7 одной проверки номера версии недостаточно. Пользовательская проблема здесь конкретна: наличие project restrictions не доказывает, что межпроектное копирование действительно запрещено. Поэтому начните с утверждения, которое можно опровергнуть: сборка достигает описанного пути, а контролируемый пограничный ввод не нарушает его границу. Короткий ответ: для github.com/lxc/incus/v7 сначала подтвердите фактическую зависимость и границу «go/github.com/lxc/incus/v7 < 7.2.0; первая исправленная версия — 7.2.0». Затем выполните только обратимую проверку на синтетических данных: сверить версию с 7.2.0 и выполнить отрицательный тест на двух пустых тестовых проектах с минимальной ролью. Результат считается доказанным лишь при рабочем positive control, явном PASS/FAIL/Unknown и отсутствии побочных изменений. Официальная запись описывает GHSA-64f3-v33m-w89f с severity high; severity помогает расставить приоритет, но не заменяет локальную проверку применимости.
Попадает ли сборка github.com/lxc/incus/v7 в затронутую границу
Проверка применимости начинается с таблицы `component / resolved version / feature state / reachable path / backport / decision`. Для github.com/lxc/incus/v7 исходная строка — «go/github.com/lxc/incus/v7 < 7.2.0; первая исправленная версия — 7.2.0». Отдельно отметьте runtime и build-time зависимость: установленный пакет может не участвовать в обработке входа, а vendored copy может не отображаться в обычном списке. Решение `affected` допустимо только при совпадении диапазона и достижимости. Решение `not affected` требует версии вне диапазона либо доказанного backport. Всё остальное остаётся `Unknown`, даже если ошибок в журнале нет.
Как провести обратимый тест для GHSA-64f3-v33m-w89f
Постройте fixture вокруг отдельной пользовательской боли, а не вокруг демонстрации уязвимости. Рабочая формулировка: сверить версию с 7.2.0 и выполнить отрицательный тест на двух пустых тестовых проектах с минимальной ролью. Материал сохраняет матрица источник–назначение–роль и проверка отсутствия побочного тома. Создайте два пустых тестовых контекста и минимальную роль. Один объект должен принадлежать разрешённой области, второй — соседней запрещённой; имена и идентификаторы только синтетические. Сначала подтвердите positive control внутри разрешённой области, затем выполните единственный отрицательный запрос. Положительный контроль подтверждает, что разрешённая ветка функционирует; отрицательный — что конкретная граница закрыта. Сохраните hash входа, версию harness и нулевые счётчики побочных действий. Повторять сценарий на production после локального причинного результата не нужно.
Какие наблюдения означают PASS, FAIL или Unknown
Не смешивайте факт обновления и факт исправления. Первый подтверждает dependency inventory, второй — fixture с контролями. Запишите роль, область владельца, тип операции, HTTP/handler-результат и неизменность обоих тестовых объектов. Сообщение интерфейса само по себе недостаточно: сверяйте итоговое состояние через разрешённый read-back или журнал аудита без значений секретов. PASS: разрешённая операция работает, а пересечение границы отклоняется до изменения состояния. FAIL: минимальная роль получает данные или создаёт связь вне своей области. UNKNOWN: контроль не сработал, provenance сборки неизвестен или read-back недоступен. Если тест расходится с advisory, сначала проверьте fork, feature flags и выбранную ветку обработки. Не повышайте FAIL до заявления об эксплуатации: он означает лишь нарушение локального тестового invariant. Итоговый пакет должен позволять владельцу повторить проверку на той же сборке.
Что делать после проверки github.com/lxc/incus/v7
Не меняйте конфигурацию вслепую. Сначала сохраните зависимости и тестовый baseline, затем обновите github.com/lxc/incus/v7 до исправленной ветки и повторите одинаковый сценарий. Если результат не совпал, откатите только изменение пакета и проверьте provenance. Не используйте реальные аккаунты, арендаторов, активы, токены или производственные журналы; при необходимости чужих данных передайте проверку владельцу системы. Эскалация нужна, когда доказательство требует production trace, реальных учётных данных, необратимой миграции или спорного толкования upstream. В обращение включайте только обезличенные наблюдения и контрольные hashes.
Какой пакет доказательств сохранить для GHSA-64f3-v33m-w89f
Evidence-карта этой проверки начинается не с общего списка полей, а с отдельной боли: наличие project restrictions не доказывает, что межпроектное копирование действительно запрещено. Проверяемая гипотеза формулируется как «сверить версию с 7.2.0 и выполнить отрицательный тест на двух пустых тестовых проектах с минимальной ролью». Её практический результат — матрица источник–назначение–роль и проверка отсутствия побочного тома. Причина не объединять страницу с соседним advisory: Отдельная версия и механизм GHSA-64f3-v33m-w89f: Incus has a project restriction bypass for custom volume copy across projects. Ответ строится вокруг конкретной границы пакета github.com/lxc/incus/v7 и не заменяется общим советом по обновлению. В карточке GHSA-64f3-v33m-w89f сохраните точное имя go/github.com/lxc/incus/v7, resolved version, digest или commit, состояние функции, границу «< 7.2.0 → 7.2.0», дату fixture, hash синтетического ввода и отдельные результаты positive и negative control. Поля наблюдения зависят от механизма категории `boundary`: для границы доступа важны владелец и неизменность объекта; для парсера — нормализованный результат и отсутствие выполнения; для resource-case — время, память и доступность следующего запроса. Содержание входа, токены, адреса, полные логи и пользовательские данные не прикладывайте. Итоговая строка должна позволить другому специалисту повторить решение именно для github.com/lxc/incus/v7, не получая доступ к production. Если upstream summary, локальная сборка и результат fixture расходятся, запишите расхождение дословно как Unknown и передайте его maintainer; не заменяйте отсутствующее доказательство предположением о том, что обновление «скорее всего» достаточно.
Материал подготовлен редакцией VOne с помощью ИИ; версионные границы, прямые источники, безопасный fixture, критерии решения, privacy-ограничения и отсутствие рекламных обещаний перепроверены человеком.
Источники и проверка
- GitHub Reviewed Advisory GHSA-64f3-v33m-w89f проверено 2026-08-31
- Upstream security source for github.com/lxc/incus/v7 проверено 2026-08-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.