Ochenstarik 771c252e79 chore(agents): приёмка PR #63 и задание Codex по cosign

Пара «задание — разбор» по PR #63 перенесена в agents/_accepted/ с
основанием приёмки и перечнем того, чего приёмка не доказывает: тесты
главным агентом не запускались, на машине приёмки нет .NET SDK.

Задание Codex требует определить версию cosign у installer 4.1.2, сойтись
с потребителем по формату подписи и предъявить прогон релизного пути с
перечнем шагов, пропущенных при репетиции.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-20 00:11:33 +07:00

4.8 KiB

Raw Blame History

Доказать или отклонить обновление cosign-installer до 4.1.2

Кому: codex
Дата: 2026-08-19
От кого: главный агент (claude)
Ветка: codex/cosign-installer-rehearsal
Файл отчёта: ../done/2026-08-19-cosign-installer-rehearsal.md

Что нужно сделать

Открыт PR #45: sigstore/cosign-installer 3.5.0 → 4.1.2 в .github/workflows/linux-release.yml, два вхождения (строки 26 и 253). Слиянию он не подлежит, пока не предъявлено доказательство, что подпись релиза после смены версии остаётся проверяемой. Нужно это доказательство — либо обоснованный отказ от обновления.

Ответить требуется на три вопроса, каждый — фактом, а не рассуждением:

Какую версию cosign ставит cosign-installer@v4.1.2 по умолчанию. В workflow версия cosign не закреплена (cosign-release не задан), так что она определяется installer'ом. Сейчас это не определено.
Совместим ли формат подписи, которую произведёт этот cosign, с потребителем. deploy/ochenstarik-server-monitor-manager.sh:34 закрепляет COSIGN_VERSION="v3.1.3" с проверкой SHA-256 и проверяет подпись через cosign verify-blob с отдельным сертификатом Fulcio. Producer и consumer должны сойтись по формату.
Проходит ли полный релизный путь. Прогнать Release pipeline на репетиционном теге и предъявить, что подпись произведена, а Release Verification её проверила на чистом хосте.

Границы

Только .github/workflows/linux-release.yml, deploy/** и релизные тесты. Не трогать src/**, консоль, Desktop и agents/ кроме своих папок. Не выпускать настоящий релиз и не двигать существующие теги.

Если по ходу выяснится, что для доказательства нужно закрепить версию cosign явно (cosign-release) или перевести действие с тега на SHA — это предложение в отчёт, а не самовольная правка: закрепление cosign-installer тегом вместо SHA уже числится отдельным замечанием.

Как проверить результат

ссылки на прогоны Release pipeline и Release Verification с репетиционным тегом и их фактический итог;
вывод шага, который печатает версию установленного cosign;
вывод проверки подписи потребителем.

Отдельное требование, из-за которого задание и появилось. Репетиция через workflow_dispatch идёт по refs/heads/main, поэтому шаги, закрытые условием refs/tags/*, в ней не исполняются. Так был сожжён alpha.19: репетиция была зелёной, а на теге упала сверка DEFAULT_RELEASE_TAG. В отчёте требуется явно показать, какие шаги при репетиции исполнялись, а какие пропущены — списком. Зелёная репетиция без этого списка доказательством не считается.

Контекст и ограничения

docs/release-policy.md фиксирует четыре поломки контракта producer/consumer по cosign: alpha.12 (подпись без сертификата Fulcio), alpha.13 (то же), alpha.17 (cosign v3 потребовал явный bundle или legacy detached-output), alpha.18 (исправление негативного теста под detached-output). Пятая поломка обойдётся ещё в один сожжённый номер версии.

Сожжённые номера — alpha.10, alpha.11, alpha.19; они не переиспользуются.

Приемлемый результат задания — «обновление отклонено, причина такая-то». Неприемлемый — «обновил, CI зелёный».

4.8 KiB Raw Blame History Unescape Escape