Практическая проверка org.graylog2:graylog2-server по GHSA-q79r-r9xg-r863: диапазон версий, безопасный локальный fixture, критерии PASS/FAIL/Unknown, stop-rule и пакет данных для поддержки без production-секретов.
Что именно проверить в org.graylog2:graylog2-server
У org.graylog2:graylog2-server проверяется не абстрактная «безопасность», а узкое правило из GHSA-q79r-r9xg-r863. Команда сталкивается с тем, что роль может выглядеть ограниченной в интерфейсе, но служебный endpoint возвращает больше данных. Опорная последовательность: определить версию, доказать достижимость, выполнить обратимый отрицательный сценарий и сравнить его с положительным. Короткий ответ: для org.graylog2:graylog2-server сначала подтвердите фактическую зависимость и границу «maven/org.graylog2:graylog2-server >= 7.1.0, <= 7.1.3; первая исправленная версия — 7.1.4». Затем выполните только обратимую проверку на синтетических данных: сверить версию 7.1.4 и сравнить ответы тестовой ограниченной роли до и после обновления без запроса производственных значений. Результат считается доказанным лишь при рабочем positive control, явном PASS/FAIL/Unknown и отсутствии побочных изменений. Такой порядок защищает от ложного PASS после поверхностного обновления.
Попадает ли сборка org.graylog2:graylog2-server в затронутую границу
Проверка применимости начинается с таблицы `component / resolved version / feature state / reachable path / backport / decision`. Для org.graylog2:graylog2-server исходная строка — «maven/org.graylog2:graylog2-server >= 7.1.0, <= 7.1.3; первая исправленная версия — 7.1.4». Отдельно отметьте runtime и build-time зависимость: установленный пакет может не участвовать в обработке входа, а vendored copy может не отображаться в обычном списке. Решение `affected` допустимо только при совпадении диапазона и достижимости. Решение `not affected` требует версии вне диапазона либо доказанного backport. Всё остальное остаётся `Unknown`, даже если ошибок в журнале нет.
Как провести обратимый тест для GHSA-q79r-r9xg-r863
Рекомендуемая обратимая проверка: сверить версию 7.1.4 и сравнить ответы тестовой ограниченной роли до и после обновления без запроса производственных значений. Практический артефакт — контракт разрешённых полей и минимальный пакет доказательств для владельца Graylog. Создайте два пустых тестовых контекста и минимальную роль. Один объект должен принадлежать разрешённой области, второй — соседней запрещённой; имена и идентификаторы только синтетические. Сначала подтвердите positive control внутри разрешённой области, затем выполните единственный отрицательный запрос. До запуска запишите ожидаемый результат positive control и отрицательного случая. После каждого шага сравните состояние с исходным снимком и удалите временные сущности. Fixture должен отвечать только на один вопрос из GHSA-q79r-r9xg-r863; добавление реального трафика, секретов или чужих объектов ухудшает доказательство, а не делает его убедительнее.
Какие наблюдения означают PASS, FAIL или Unknown
Результат удобнее фиксировать одной строкой на каждую сборку. Поля: package/digest, feature state, positive control, negative fixture, ошибка или статус, read-back и решение. Запишите роль, область владельца, тип операции, HTTP/handler-результат и неизменность обоих тестовых объектов. Сообщение интерфейса само по себе недостаточно: сверяйте итоговое состояние через разрешённый read-back или журнал аудита без значений секретов. PASS: разрешённая операция работает, а пересечение границы отклоняется до изменения состояния. FAIL: минимальная роль получает данные или создаёт связь вне своей области. UNKNOWN: контроль не сработал, provenance сборки неизвестен или read-back недоступен. Добавьте владельца и срок повторной проверки для временной меры. Не переносите наблюдение со staging на другой image без сверки digest: одинаковый номер версии может скрывать разный backport.
Что делать после проверки org.graylog2:graylog2-server
Закрытие задачи требует не только нового номера версии. Нужны исходный inventory, подтверждённый источник релиза, повторный control и результат read-back. Исправленная граница начинается с 7.1.4. Не используйте реальные аккаунты, арендаторов, активы, токены или производственные журналы; при необходимости чужих данных передайте проверку владельцу системы. Передавайте в поддержку только package, digest, минимальную конфигурацию, тип fixture, решение и ссылки; секреты и полные production-логи исключите. Если upstream и локальное наблюдение расходятся, статус остаётся Unknown до ответа maintainer.
Какой пакет доказательств сохранить для GHSA-q79r-r9xg-r863
Evidence-карта этой проверки начинается не с общего списка полей, а с отдельной боли: роль может выглядеть ограниченной в интерфейсе, но служебный endpoint возвращает больше данных. Проверяемая гипотеза формулируется как «сверить версию 7.1.4 и сравнить ответы тестовой ограниченной роли до и после обновления без запроса производственных значений». Её практический результат — контракт разрешённых полей и минимальный пакет доказательств для владельца Graylog. Причина не объединять страницу с соседним advisory: Отдельная версия и механизм GHSA-q79r-r9xg-r863: Graylog Server: System Catalog titles endpoint can be used to retrieve values of protected database fields. Ответ строится вокруг конкретной границы пакета org.graylog2:graylog2-server и не заменяется общим советом по обновлению. В карточке GHSA-q79r-r9xg-r863 сохраните точное имя maven/org.graylog2:graylog2-server, resolved version, digest или commit, состояние функции, границу «>= 7.1.0, <= 7.1.3 → 7.1.4», дату fixture, hash синтетического ввода и отдельные результаты positive и negative control. Поля наблюдения зависят от механизма категории `boundary`: для границы доступа важны владелец и неизменность объекта; для парсера — нормализованный результат и отсутствие выполнения; для resource-case — время, память и доступность следующего запроса. Содержание входа, токены, адреса, полные логи и пользовательские данные не прикладывайте. Итоговая строка должна позволить другому специалисту повторить решение именно для org.graylog2:graylog2-server, не получая доступ к production. Если upstream summary, локальная сборка и результат fixture расходятся, запишите расхождение дословно как Unknown и передайте его maintainer; не заменяйте отсутствующее доказательство предположением о том, что обновление «скорее всего» достаточно.
Материал подготовлен редакцией VOne с помощью ИИ; версионные границы, прямые источники, безопасный fixture, критерии решения, privacy-ограничения и отсутствие рекламных обещаний перепроверены человеком.
Источники и проверка
- GitHub Reviewed Advisory GHSA-q79r-r9xg-r863 проверено 2026-08-31
- Upstream security source for org.graylog2:graylog2-server проверено 2026-08-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.