server-monitor-manager/agents/antigravity/inbox/from-smm-deliverables/Старые задачи/smm-antigravity-task-cert-pr-and-deps-2026-08-10.md
Ochenstarik 23eb3f5233 chore(agents): разбор рабочих папок с диска на 2026-08-18
Задания, отчёты и патчи, лежавшие в 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>
2026-08-18 14:19:54 +07:00

9.3 KiB
Raw Permalink Blame History

Antigravity: довести сертификаты до PR и разобрать dependabot

Состояние

  • main @ 80b4797 — содержит fix(enrollment): repair node enrollment path (#24) от Hermes;
  • ветка antigravity/cert-lifecycle @ 9d2fe1c — CI зелёный, с main сливается без конфликтов, PR не открыт;
  • открыто шесть PR от dependabot: #18#23.

Часть 1 — доделать antigravity/cert-lifecycle

Работа принята по существу: ClientCertificateDays в ControlOptions с умолчанием 30 и сохранённым [DynamicDependency], AddYears(1) заменён на AddDays(...), автопродление Agent при остатке меньше трети с сохранением работы при недоступном Hub, событие certificate.expiring, docs/certificate-rotation.md, все семь обязательных тестов, 101 тест зелёный. Границы соблюдены — ни одного файла из области Hermes.

Осталось пять пунктов.

1.1. Ребейз на текущий main

Ветка сделана до merge #24. Конфликтов нет, но база должна быть актуальной: #24 менял привязку конфигурации Agent, а ваша работа трогает AgentClient.cs.

1.2. Убрать TEST_EVIDENCE.md из репозитория

Файл закоммичен в корень. Отчёт — артефакт PR, а не содержимое репозитория. Перенести содержимое в описание PR, файл удалить из ветки.

1.3. Проверка на trimmed-артефакте по production-пути

Сделано было так:

dotnet publish ... -r win-x64 --self-contained -p:PublishTrimmed=true
.\ochenstarik-smm-control.exe --Control:ClientCertificateDays 999

Это командная строка на win-x64. В проде конфигурация приходит переменными окружения из control.env через EnvironmentFile= в systemd-юните, на linux-x64. Сломанным под триммингом был именно env-путь — в AgentOptions не оказалось [DynamicDependency], и Agent молча брал умолчания.

Повторить проверку так, как оно работает в бою:

dotnet publish src/ServerMonitorManager.Control/ServerMonitorManager.Control.csproj \
  -c Release -r linux-x64 --self-contained -p:PublishTrimmed=true -p:PublishSingleFile=true -o /tmp/ctl
Control__ClientCertificateDays=999 /tmp/ctl/ochenstarik-smm-control

Ожидается отказ старта с ошибкой валидации. Если сервис стартует — значение не дошло, и настройка в проде работать не будет.

Дополнительно проверить обратное: валидное значение из переменной окружения действительно применяется к выпускаемому сертификату, а не подменяется умолчанием 30. Например Control__ClientCertificateDays=45, выпустить сертификат, посмотреть notAfter.

Вывод обеих проверок приложить к PR.

1.4. Убрать дублирующий эндпоинт продления

В Control/Program.cs появились два пути продления:

  • agents.MapPost("/certificate/renew") — в группе с RequireAuthorization("Agent"), всё правильно;
  • app.MapPost("/api/v1/certificates/renew") — без RequireAuthorization, отсекает чужих случайной проверкой на пустой entityId и разветвляется по claim роли внутри.

Второй ведёт себя fail-closed, но держится не на конвейере авторизации, а на том, что у неаутентифицированного запроса не окажется claims. Это не соглашение проекта: рядом в том же файле все защищённые эндпоинты объявлены через группы с политикой.

Выбрать одно:

  • предпочтительно — удалить app.MapPost("/api/v1/certificates/renew"), оставив продление Agent в группе agents, а продление Operator добавить в группу control с RequireAuthorization("Operator");
  • либо оставить один общий эндпоинт, но объявить его через группу с политикой, требующей аутентифицированную identity, и разветвление по роли выполнять уже внутри.

Добавить тест: запрос на продление без клиентского сертификата отклоняется, и отклоняется конвейером, а не обработчиком.

1.5. Открыть PR

После пунктов 1.11.4. Описание PR заполнять после завершения CI, со ссылками на конкретные прогоны.


Часть 2 — dependabot, отдельным PR каждый

Шесть открытых PR. Сливать пачкой нельзя: три из них меняют то, от чего зависит воспроизводимость и цепочка поставки.

2.1. Безопасные — слить после зелёного CI

  • #22 Microsoft.NET.Test.Sdk 18.0.1 → 18.8.1;
  • #19 actions/setup-dotnet 5.4.0 → 6.0.0;
  • #18 softprops/action-gh-release 2.6.2 → 3.0.2.

Для двух последних убедиться, что dependabot заменил SHA, а не вернул плавающий тег: инвариант «ни одного плавающего тега в uses:» из PR #14 должен сохраниться. Проверять на каждом PR:

grep -rn 'uses:.*@v[0-9]' .github/workflows/ && echo "НАЙДЕН ПЛАВАЮЩИЙ ТЕГ" || echo "все запинены"

action-gh-release 3.0.x — мажорный скачок, посмотреть changelog на предмет изменения имён входных параметров: он используется в release-workflow, а те не запускаются на pull request, поэтому CI поломку не покажет. Это ровно тот класс дефектов, что вы уже ловили в PR #14 с permissions. Проверять actionlint, а не полагаться на зелёный PR.

2.2. Требуют внимания

  • #21 actions/checkout 6.1.0 → 7.0.1 и #20 actions/upload-artifact 6.0.0 → 7.0.1 — мажорные. upload-artifact v7 может менять поведение при отсутствии файлов и формат имён артефактов; в linux-release.yml и windows-release.yml от имён артефактов зависит сборка релиза. Проверить, что после обновления релизные ассеты собираются с теми же именами: их знает установщик smm-setup.sh и bootstrap.

2.3. Не сливать без отдельной проверки

  • #23 SQLitePCLRaw.bundle_e_sqlite3 2.1.12 → 3.0.5.

Это мажорное обновление нативной библиотеки под SQLite, на которой держится вся база Control: enrollment, identities, links, provisioning, audit. Требуется:

  • прогон полного Control suite на Linux, не только на Windows;
  • проверка миграций на существующей базе: взять control.db, созданную текущей версией, открыть новой сборкой, убедиться, что PRAGMA user_version и данные читаются;
  • проверка backup-create и backup-restore на этой же базе;
  • проверка, что self-contained trimmed-публикация под linux-arm64 не ломается — нативные библиотеки в trimmed single-file собираются иначе, чем под x64.

Если хоть одна проверка не выполнена, PR не сливать и написать это прямо. Обновление некритично и подождёт.


Порядок

Часть 1 → 2.1 → 2.2 → 2.3. Сертификаты первыми: это пункт Горизонта 0, а обновления зависимостей подождут.

Отчёт

Раздельно: что проверено локально, что в CI со ссылками, что не проверялось и почему. По части 2 — по каждому PR отдельной строкой с вердиктом «слит / отложен / отклонён» и причиной.