Ochenstarik ddb3f559f2 chore(agents): задания по Windows-клиенту и второму потребителю cosign

Версия MSIX не менялась с 2026-07-31: Package.appxmanifest объявляет
1.0.0.6 во всех четырнадцати релизах после alpha.6, тогда как Windows
различает пакеты по версии манифеста. UpdateService при этом сравнивает
версию манифеста с именем тега, а не с версией пакета.

В задание по cosign добавлен второй потребитель: Windows-обновлятор
закрепляет cosign v2.4.0, тогда как Linux-установщик — v3.1.3. Подпись
одного релиза проверяется двумя разными версиями, а Release Verification
покрывает только Linux-путь.

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

2026-08-20 16:47:48 +07:00

6 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, с потребителями — обоими. Потребителей два, и они на разных версиях cosign:
- Linux. deploy/ochenstarik-server-monitor-manager.sh:34 закрепляет COSIGN_VERSION="v3.1.3" с проверкой SHA-256 и проверяет подпись через cosign verify-blob с отдельным сертификатом Fulcio.
- Windows. src/ServerMonitorManager.Desktop/UpdateService.cs:79 закрепляет CosignVersion = "v2.4.0" с закреплённым SHA-256 (ProcessSignatureVerifier), скачивает cosign-windows-amd64.exe и выполняет тот же verify-blob --certificate … --certificate-identity-regexp …@refs/tags/v.*.
То есть подпись одного релиза проверяется cosign v3.1.3 на Linux и cosign v2.4.0 на Windows. Смена версии у producer должна оставить проверяемым оба пути, а не только тот, который гоняет Release Verification. Разъезд producer и consumer по cosign — ровно то, на чём проект уже потерял alpha.12, alpha.13, alpha.17 и alpha.18.
Проходит ли полный релизный путь. Прогнать 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 v2.4.0, как это делает Windows-обновлятор. Release Verification гоняет только Linux-путь, поэтому Windows-потребитель ею не покрыт;
вывод шага, который печатает версию установленного 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 зелёный».

6 KiB Raw Blame History Unescape Escape