server-monitor-manager/agents/antigravity/inbox/from-smm-deliverables/Старые задачи/smm-antigravity-task-desktop-update-proof-2026-08-13.md

Antigravity: доказать проверку подписи на стороне Desktop

Состояние

main @ b0ad40c, открытых PR нет, одна ветка, CI зелёный. Ваша работа по очереди B и проверке релиза вошла в main в составе PR #41.

Ветка: antigravity/desktop-update-proof.

---

Зачем

UpdateService умеет проверять подпись manifest перед обновлением: identity подписи вшита константой, при несовпадении хэша или подписи обновление отклоняется. Тесты к нему есть — но все они работают на синтетических данных, которые тот же код и порождает.

Ни один тест не подаёт UpdateService настоящий manifest, настоящую подпись и настоящий сертификат из опубликованного релиза. То есть проверено, что код отвергает то, что мы сами испортили, и не проверено, что он принимает то, что реально выпускается.

Ровно этот разрыв уже дважды дорого стоил. Проверка релиза на стороне Linux падала не из-за логики, а из-за имени ассета и отсутствующего сертификата — вещей, которые синтетические данные не воспроизводят. На стороне Windows такой проверки нет вовсе.

Что сделать

Тест, который берёт материал из настоящего релиза и прогоняет через UpdateService.

1. Приёмочный тест против опубликованного релиза. Скачать server-monitor-manager-manifest.json, .sig и .pem тега v0.1.0-alpha.14 публичным curl — без gh и без токена, как это делает Desktop у пользователя, — и убедиться, что UpdateService принимает их и извлекает ожидаемую версию и хэши.

   Тег задать параметром с умолчанием, чтобы прогон не привязывался к одному релизу навсегда.

2. Негативные случаи на том же материале, а не на сгенерированном: подменённый хэш в настоящем manifest; настоящий manifest с подписью от другой identity; отсутствующий сертификат; сертификат от другого workflow. Все четыре — отказ.

3. Сетевой тест не должен ронять обычный прогон. Пометить его категорией и включать отдельно — в windows-build.yml шагом, который явно её запускает. Разработчик без сети должен получать зелёный основной набор.

4. Проверить, что Windows CI действительно исполняет эти тесты. Сейчас Test Desktop security запускает проект целиком; убедиться, что новая категория в него попадает, а не отфильтровывается молча. Продемонстрировать намеренной поломкой: испортить ожидаемую identity, показать красный прогон, откатить.

Границы

Hermes выпускает v0.1.0-alpha.14 и добавляет в deploy/smm-setup.sh команды install-hub и install-node. Он же правит docs/linux-bootstrap.md и docs/release-policy.md.

Не трогать: deploy/**, .github/workflows/linux-*.yml, .github/workflows/release-verification.yml, tests/release-verification/**, docs/**.

Ваша область: src/ServerMonitorManager.Desktop/UpdateService.cs, tests/ServerMonitorManager.Desktop.Security.Tests/**, и при необходимости шаг запуска тестов в .github/workflows/windows-build.yml — этот файл Hermes сейчас не трогает, но изменение согласовать в отчёте.

Задача зависит от выпуска alpha.14. До его публикации можно писать тесты против v0.1.0-alpha.9, но окончательный прогон — против alpha.14: это первый релиз, где сертификат публикуется и подпись проверяема целиком.

Критерий приёмки

• тест принимает настоящий manifest, подпись и сертификат опубликованного релиза;
• четыре негативных случая на настоящем материале отвергаются;
• сетевые тесты отделены категорией и не ломают офлайн-прогон;
• Windows CI их исполняет — подтверждено намеренной поломкой со ссылкой на красный прогон;
• загрузка идёт публичным curl, без gh и без токена;
• git diff --name-only main не выходит за границы;
• CI зелёный, PR не смержен.

Отчёт

Раздельно: локально, в CI со ссылками, не запускалось и почему. Если тест против настоящего релиза обнаружит расхождение — вынести отдельным разделом, это результат, а не помеха.

---

Доработка PR #55 — отделить сетевые тесты в workflow

Проверено 2026-08-18. Выполнено почти всё, и выполнено хорошо:

• приёмочный тест берёт настоящие manifest, подпись и сертификат опубликованного релиза публичным HTTP, без gh и без токена;
• четыре негативных случая на настоящем материале отвергаются;
• исполнение в Windows CI доказано намеренной поломкой со ссылкой на красный прогон 32049692162 и на зелёные после отката. Это ровно то, что требовалось пунктом 4, и это первый в проекте отчёт, где утверждение об исполнении подкреплено падением;
• границы соблюдены: один файл.

Не выполнен пункт 3. Требовалось: пометить сетевые тесты категорией и включать их отдельным шагом в windows-build.yml, чтобы разработчик без сети получал зелёный основной набор. Категория [Trait("Category", "LiveRelease")] проставлена, но .github/ в PR не изменён вовсе. Следствия:

• шаг Test Desktop security по-прежнему запускает проект целиком, поэтому каждый прогон Windows CI теперь зависит от доступности github.com. При проверке этого PR GitHub отдавал HTTP 503 — то есть отказ внешней службы покрасит основной гейт на изменениях, не имеющих к релизам никакого отношения;
• разработчик без сети получает красный набор, если не вспомнит про флаг --filter Category!=LiveRelease. Требование было противоположным: зелёный по умолчанию.

Сделать в windows-build.yml два шага вместо одного:

1. Test Desktop security — dotnet test ... --filter Category!=LiveRelease. Основной гейт, без сети;
2. Test Desktop security (live release) — dotnet test ... --filter Category=LiveRelease. Сетевой, обязательный, но отделённый: по его падению сразу видно, что дело в релизе или в сети, а не в логике.

windows-build.yml в запрещённый список не входит — пункт 3 прямо предписывал его изменить.

Отдельно, на ваше решение. Тег зафиксирован как v0.1.0-alpha.14 с переопределением через SMM_TEST_RELEASE_TAG. С тех пор вышли alpha.15–18, и проверка релиза в CI зелёная против alpha.18. Тест доказывает, что проверяется релиз четырёхдневной давности, а не тот, который получают пользователи. Разумно передавать в шаге live-release текущий тег, оставив значение по умолчанию как есть. Если считаете, что фиксация на заведомо годном релизе важнее, — напишите это обоснованием в отчёте, но тогда нужен способ узнать, что новый релиз перестал проходить desktop-проверку.