Кратко

  • Изменение Rapport от 4 сентября 2026 года разделило два сценария RFC 9286. Тест для той же CA сначала создаёт исправный кеш, затем удаляет ca2.mft и по-прежнему ожидает шесть VRP, включая два кешированных результата пострадавшей CA.
  • Комментарий в сценарии требует, чтобы валидатор предупредил об отсутствующем манифесте. Но единственная следующая строка check_logfile начинается с #, поэтому оболочка не исполняет её в зафиксированном коммите.
  • RFC 9286 отдельно требует предупреждение с причиной прекращения обработки и рекомендует уведомлять человека, а также рекомендует продолжать использовать кешированные объекты той же CA до их устаревания или успешной замены.
  • Полная приёмка требует двух колонок: решения о кеше и семантического сигнала оператору. Сохранность VRP не доказывает предупреждение, а предупреждение не доказывает правильность сохранённого набора.

Шесть результатов после исчезновения одного файла

Сценарий начинается с намеренно исправного состояния. Два экземпляра CA дают по два VRP, и первый запуск формирует известный набор из четырёх результатов вместе с успешно проверенным кешем. Затем сценарий подготавливает второе состояние: добавляет третий экземпляр CA и удаляет манифест ca2.mft, относящийся ко второй CA. Выбранный relying party запускается повторно при отключённом HTTP-доступе. Возможность незаметно получить отсутствующий файл другим путём исключена.

Во втором запуске ожидается уже шесть VRP. Два результата первой CA остаются, два результата новой третьей CA добавляются, а два результата второй CA переносятся из предыдущего успешного кеша. Таким образом тест фиксирует важное свойство непрерывности: временная недоступность манифеста того же экземпляра CA не должна автоматически стирать последний валидированный набор объектов этой CA.

Это не поблажка недостоверному состоянию, а ограничение последствий сбоя публикации. Если после одной неудачной загрузки немедленно отбросить всё ранее проверенное, relying party может принять действительный маршрут за недействительный или при иных исходных условиях допустить противоположную ошибку. Ограниченное продолжение последнего успешного состояния не позволяет превратить транспортную проблему в фиктивное изменение маршрутной авторизации.

Именно спокойный вид результата делает предупреждение обязательной частью контроля. Непосредственно перед проверкой шести VRP в сценарии сказано, что валидатор должен предупредить об отсутствующем манифесте. Следующая строка содержит проверку журнала FORT, но начинается с символа комментария. Для POSIX-оболочки это текст, а не команда. Поэтому зафиксированная версия через этот путь проверяет сохранённый набор результатов, но не факт появления заявленного предупреждения.

Границы вывода здесь принципиальны. Закомментированная строка не доказывает, что FORT, Routinator, rpki-client, rpki-prover или любой другой relying party на самом деле промолчал. Она не доказывает сбой теста, ошибку в ожидаемых шести VRP или происшествие в рабочем репозитории. По ней также нельзя установить намерение сопровождающих, наличие иной проверки или срок будущего включения строки. Доказуем лишь узкий факт: исполняемый путь данного сценария в выбранной ревизии не утверждает предупреждение тем способом, который расположен рядом с проверкой результата.

Общая точка публикации не означает общую CA

RFC 9286 определяет манифест как подписанный перечень сертификатов, CRL и подписанных объектов, связанных с точкой публикации CA. Одну точку публикации могут совместно использовать несколько экземпляров CA. Однако каждый манифест описывает только связанный с ним экземпляр. Поэтому границу идентичности нельзя провести просто вокруг каталога репозитория.

Манифест обрабатывается отдельно для каждого экземпляра CA, а направление задаёт URI манифеста в SIA сертификата CA. Если манифест получить невозможно, загрузка завершается неудачно и обработка переходит в ветвь отказа именно этого экземпляра. Другие файлы в том же месте не подменяют отсутствующий манифест, а общий путь не является достаточным доказательством принадлежности кеша.

В ветви отказа стандарт формулирует два разных действия. Неудачная загрузка должна породить предупреждение с причиной прекращения обработки данного экземпляра CA; кроме того, рекомендуется уведомить человека-оператора. Отдельно relying party следует продолжать использовать кешированные объекты, связанные с тем же экземпляром, пока они не устареют или не будут заменены после успешной загрузки.

Эти действия дополняют друг друга, но не содержат друг друга. Решение о кеше отвечает, какие объекты продолжают участвовать в расчёте. Предупреждение отвечает, почему часть результата основана не на текущей загрузке, какая CA затронута и кому следует обратить внимание. Одинаковые шесть VRP могут возникнуть и после полностью свежего запуска, и после запуска с двумя перенесёнными объектами. Само число не хранит происхождение данных.

Поэтому наблюдаемость становится границей безопасности. Кеш предотвращает ненужный скачок в состоянии управления маршрутами. Сигнал не позволяет принять этот спокойный результат за полностью успешное обновление. Если тестовая система пропускает только конечное множество, оператор лишается различия между «шесть свежих VRP» и «шесть VRP, два из которых остались из-за отказа загрузки».

Стандарт допускает продолжение потому, что более поздняя загрузка может устранить проблему. До неё последний успешный набор защищает relying party от неправильного толкования временного состояния репозитория. Но отсрочка не бессрочна и не должна быть молчаливой. У объектов есть границы свежести, должна состояться новая попытка, а причина продолжения должна быть видна. Только вместе эти свойства образуют управляемую деградацию.

Соседний тест показывает недостающую половину

В том же изменении появился полезный сравнительный сценарий. В нём меняются сертификат CA и URI манифеста в SIA. Это случай повреждённого SIA с изменившейся идентичностью, а не временно отсутствующий манифест того же экземпляра. Ожидаемый набор исключает VRP пострадавшей CA и сохраняет результаты соседней и новой CA. При этом проверка предупреждения через check_logfile действительно исполняется.

Такое сравнение не даёт оснований оценивать качество конкретного продукта. Оно показывает более ограниченную и полезную вещь: Rapport умеет различать непрерывность экземпляра CA и непрерывность точки публикации, а в соседнем сценарии умеет утверждать диагностический сигнал, видимый оператору. Наблюдаемый пробел состоит в том, что при возврате к кешу той же CA эти две возможности не объединены в одном доказательстве приёмки.

Недостаточно было бы найти любую строку с уровнем warning. При повреждённом SIA результаты пострадавшей CA удаляются, при пропавшем манифесте того же экземпляра — сохраняются. Предупреждения могут понадобиться в обоих случаях, но они должны описывать разные причины и решения. Полезное утверждение связывает класс отказа, экземпляр CA и выбранное действие с кешем. Иначе тест может пройти из-за сигнала о другом событии или при неправильном наборе объектов.

Фраза FORT не должна становиться общим контрактом

Самое простое изменение — снять комментарий с существующего регулярного выражения. Но тогда точная английская фраза одного продукта станет интерфейсом для многопродуктового тестера. Формулировки журналов по уважительным причинам меняют порядок слов, пунктуацию и детализацию. Если любое такое улучшение ломает набор тестов, проверка предупреждения превращается в обременение и снова рискует быть выключенной или чрезмерно ослабленной.

Rapport выгоднее определить семантическое событие, а для каждого relying party предоставить адаптер. Минимальные поля события: класс причины «манифест не получен», устойчивая ссылка на затронутый экземпляр CA, решение продолжить работу с кешем, возраст или граница свежести кеша, серьёзность, время выпуска, а также состояние уведомления или эскалации. Адаптер может извлечь их из структурированного события, метрики, системного журнала или документированной диагностики.

Переносимость не означает расплывчатость. Формат времени, порядок полей и естественный язык могут различаться. Но причина не должна сжиматься до общей ошибки без контекста, экземпляр CA обязан быть определим, а решение о кеше не следует угадывать по числу VRP. Общая семантика отделяет обязательные сведения от допустимых различий представления.

Двухколоночная квитанция приёмки

Каждый запуск должен оставлять не только общий итог, но и квитанцию. Первая колонка описывает решение о кеше: идентификатор экземпляра CA, отпечаток текущего сертификата и SIA, последнюю успешную загрузку, набор или дайджест кешированных объектов, границу свежести, причину текущего отказа, разницу сохранённых и удалённых VRP, изоляцию соседних CA и следующую попытку.

Вторая колонка описывает операторский сигнал: распознанный семантический класс, ссылку на CA, явное решение о fallback, возраст кеша, серьёзность, время выдачи и доставку в предусмотренный журнал, метрику, дежурную службу или канал эскалации. Обе колонки должны сохранять ссылки на исходные доказательства, чтобы рецензент мог проверить не только итоговую отметку.

Такая квитанция запрещает две удобные подмены. «VRP сохранились» не означает «оператор предупреждён». «Появилось предупреждение» не означает «сохранён правильный кеш». Только независимый успех обеих колонок доказывает полную позицию стандарта: сервис продолжает работать на последнем проверенном состоянии, а ухудшение его свежести не скрыто.

Привязка к экземпляру CA особенно важна. Поскольку несколько экземпляров могут делить одну точку публикации, общий адрес не доказывает принадлежность кеша. Отпечатки сертификата и SIA, последний успешный набор и изоляция соседних CA защищают от ошибочного присоединения старых объектов к другой идентичности. Та же ссылка в предупреждении превращает общий сигнал о репозитории в основание для конкретного действия.

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

LACNIC представил Rapport как тестер RPKI relying party, а репозиторий называет проект ранней разработкой. Это не уменьшает ценность открытых сценариев. Напротив, они показывают, как нормативные формулировки превращаются в исполняемые ожидания, и где доказательство пока остаётся незавершённым.

Зафиксированная версия поддерживает четыре ограниченных вывода. Изменение от 4 сентября 2026 года разделило смену идентичности и fallback той же CA. Второй сценарий ожидает шесть VRP, в том числе два из затронутого кеша. Комментарий требует предупреждения, но проверяющая строка закомментирована. RFC 9286 отдельно формулирует предупреждение и продолжение кеша, а соседний сценарий показывает способность среды проверять журнал.

Материал не подтверждает обвинение в адрес валидатора, рабочее применение Rapport или мотив сопровождающих. Проверяемый следующий шаг — не догадка об этих неизвестных. Он состоит в том, чтобы объявлять два отдельных результата и хранить доказательный путь для каждого.

Источники