ddb3f559f2
Версия 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>
85 lines
6 KiB
Markdown
85 lines
6 KiB
Markdown
# Доказать или отклонить обновление 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, с
|
||
потребителями — обоими.** Потребителей два, и они на разных версиях
|
||
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.
|
||
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 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 зелёный».
|