23eb3f5233
Задания, отчёты и патчи, лежавшие в C:\Users\Ochenstarik\projects и в домашней папке, перенесены в agents/. Разложено по агентам там, где имя файла позволяло определить автора; остальное — в _salvage-2026-08-18/ и разбирается вручную. Патчи в notes/salvage-2026-08-18/ — незакоммиченная работа из брошенных рабочих копий: она существовала только на диске. Тяжёлое (релизные архивы, инсталляторы, наборы данных) в репозиторий не попало: оно лежит рядом, в Agent_projects/_archive и Agent_projects/_data. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
80 lines
9.8 KiB
Markdown
80 lines
9.8 KiB
Markdown
# 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-проверку.
|