# Доказать или отклонить обновление 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).
Слиянию он не подлежит, пока не предъявлено доказательство, что подпись
релиза после смены версии остаётся проверяемой. Нужно это доказательство —
либо обоснованный отказ от обновления.

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

1. **Какую версию cosign ставит `cosign-installer@v4.1.2` по умолчанию.**
   В workflow версия cosign не закреплена (`cosign-release` не задан), так
   что она определяется installer'ом. Сейчас это не определено.
2. **Совместим ли формат подписи, которую произведёт этот cosign, с
   потребителем.** `deploy/ochenstarik-server-monitor-manager.sh:34`
   закрепляет `COSIGN_VERSION="v3.1.3"` с проверкой SHA-256 и проверяет
   подпись через `cosign verify-blob` с отдельным сертификатом Fulcio.
   Producer и consumer должны сойтись по формату.
3. **Проходит ли полный релизный путь.** Прогнать `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 зелёный».