92 lines
7.4 KiB
Markdown
92 lines
7.4 KiB
Markdown
# Критический анализ отчёта Opus (мой разбор, 2026-10-05)
|
||
|
||
> Кем: я (DeepSeek). Что: критический разбор отчёта Opus
|
||
> (`opus-report-2026-10-05.md`) по архитектуре shared-sqs.
|
||
> Метод: ключевые утверждения Опуса перепроверялись по коду напрямую, а не
|
||
> принимались на веру. Источники — «файл:строка».
|
||
|
||
---
|
||
|
||
## Что я перепроверил по коду (факты)
|
||
|
||
| Утверждение Опуса | Вердикт | Источник в коде |
|
||
|---|---|---|
|
||
| P0.1: SecretKey детерминирован из email + соль в исходнике | ✅ подтверждено | `tenant_store.go:289-292` `secretKeyFromEmail` = `SHA256(lower(email)+":shared-sqs:secret-key:v1")`; соль — константа `secretKeySalt` (`tenant_store.go:286`); `accessKeyFromEmail` = `SHA256(email)[:12]` |
|
||
| P0.2: JWT без проверки подписи, доверие на PingNubesAPI | ✅ подтверждено | `jwt.go` — парсинг структуры + `exp`; `PingNubesAPI` принимает, если хоть один стенд не 401/403 |
|
||
| Кэш: отозванный токен живёт до ~7 мин | ✅ подтверждено | `cache.go`: `cacheTTL=5m`, `cacheGraceTTL=2m` |
|
||
| Глобальный мьютекс на весь сервис | ✅ подтверждено | `globals.go:20-23` — один `SyncQueues.RWMutex` + `Queues map[string]*Queue` |
|
||
| Сиротство очередей при пересчёте legacy-тенанта | ✅ подтверждено | `tenant_store.go:202-205` — комментарий в коде сам это описывает |
|
||
| MessageRetentionPeriod не реализован | ✅ подтверждено | `models.go` — `// TODO - not used` |
|
||
|
||
Ложных утверждений не найдено.
|
||
|
||
---
|
||
|
||
## Сильные стороны отчёта
|
||
|
||
1. **P0.1 — самая ценная находка.** Детерминированный вывод SecretKey из
|
||
публичного email — реальный, доказуемый по коду дефект. Указан не только
|
||
механизм, но и точные функции. Именно это реально блокирует «готовность SQS».
|
||
2. **Верно разделены SigV4 и JWT.** SigV4 проверяется полноценно
|
||
(`auth_middleware.go`: canonical request, `subtle.ConstantTimeCompare`,
|
||
clock skew, presigned); JWT — нет. Большинство поверхностных ревью их путают.
|
||
3. **Классификация P0/P1/P2 адекватна** — безопасность+durability отделены от
|
||
масштабируемости и гигиены.
|
||
4. **Пункты 3–7** (глобальный лок, SPOF, async-Redis, нет RetentionPeriod,
|
||
плоский слайс) — архитектурно точны.
|
||
5. **Раздел «противоречия док↔код» конкретен** (особенно №1: док про
|
||
`sub`/`bySub`/`sless-`, код про `email`/`byEmail`/`t-`).
|
||
|
||
---
|
||
|
||
## Слабые места и оговорки
|
||
|
||
1. **P0.2 переоценён как самостоятельный «критичный».** Вектор «подмена email
|
||
→ доступ» опасен **только в связке с P0.1**: неверный email даёт чужие креды,
|
||
потому что креды детерминированы из email. Исправь P0.1 (случайные креды в
|
||
Redis) — и неверный email из JWT уже не даст чужих ключей, только
|
||
провиженинг под чужим именем (менее критично). Опус не связал P0.1 и P0.2
|
||
явно, хотя атака работает попарно. Стоит оформить как один инцидент.
|
||
|
||
2. **П.4 «SPOF/нет горизонтального масштабирования»** — справедливо
|
||
архитектурно, но сервис и проектировался single-instance managed
|
||
HTTP-контейнером (README). Это осознанное ограничение, а не баг. В разряд
|
||
«высокого риска сейчас» ставить преждевременно — это долгосрочная
|
||
архитектурная развилка, а не текущий блокер.
|
||
|
||
3. **П.5 (async-Redis = потеря подтверждённых сообщений) — полуверно.**
|
||
Сообщение в памяти уже есть (клиент получил 200 = сообщение в памяти,
|
||
источнике правды). Теряется только при краше пода **до** async-`HSet`, и
|
||
только это узкое окно. Окно реально, но «нарушение durability» подано
|
||
сильнее, чем есть: теряются не все сообщения, а только при краше в окне.
|
||
|
||
4. **П.10 (timing side-channel admin-токена)** — технически верно, но admin-токен
|
||
приходит как высокоэнтропийный bearer; практическая эксплуатируемость timing-атаки
|
||
через сеть у одного короткого сравнения ничтожна. Формально в P2 и есть, но
|
||
вес в подаче чуть завышен.
|
||
|
||
5. **П.14 (`/metrics` публичен)** — стоит оговорка: лейбл `tenant` = tenantID
|
||
(`t-...`), а НЕ SecretKey. Утечка реальна (число очередей/сообщений по
|
||
тенанту), но это не утечка кредов. Формулировка корректна, но без оговорки
|
||
читается страшнее.
|
||
|
||
6. **Пробел контекста (не ошибка Опуса, а следствие моего allowlist-запрета):**
|
||
отчёт не отделяет «код-блокировку» от «платформенной блокировки» — периодические
|
||
таймауты ~31–33с и MSS-баг для тел >~1400 байт (разобрано в
|
||
`doc/thinking/nubes-ticket.md`). Даже идеальный код их не уберёт. Итоговый
|
||
вывод о «готовности SQS» надо читать с этой поправкой.
|
||
|
||
---
|
||
|
||
## Итоговая оценка
|
||
|
||
Отчёт — **добротный, по фактам точный**. Из 16 пунктов рисков ложных нет;
|
||
спорные — только **вес/приоритет**:
|
||
- P0.2 связать с P0.1 (один инцидент);
|
||
- п.4 (SPOF) и п.10 (timing) слегка переоценены для текущей single-instance роли.
|
||
|
||
Главная ценность: **P0.1 (детерминированный SecretKey)** — подтверждённый по
|
||
коду блокер готовности, который до этого так жёстко не формулировался.
|
||
Единственный реальный пробел — платформенный контекст (таймауты/MSS), но он
|
||
возник из моего же allowlist и устраняется дополнением, не исправлением.
|