Files
bare/docs/decisions/042-current-room-key-order.md
mayatnikovandClaude Opus 5 db45978b16 Этап 6: закалка — лимиты ADR-021, аудит модели угроз, сверка документов
Лимиты: все четыре правила ADR-021 — регистрация 5/час на IP, вход 10/10 мин
на IP и ник, сообщения 30/мин, прочие изменяющие 60/мин; 429 с Retry-After;
X-Real-IP читается только с loopback, иначе адрес соединения — иначе заголовок
отменял бы лимит на IP; карты вёдер ограничены поколениями.

Аудит нашёл то, что пропустили пять раундов ревью:
ADR-056: nginx вёл access_log с IP и полными путями вопреки обещанию deploy.md.
Ники и социальный граф ложились в /var/log/nginx рядом с чистым журналом bare.
ADR-058: «выйти на других устройствах» не обрывал уже открытый SSE — отозванная
сессия продолжала получать сообщения.
ADR-059: промежуточный ключ комнаты был невосстановим. Участник, пропустивший
офлайн два rekey подряд, навсегда не расшифровал бы сообщения среднего ключа —
вопреки обещанию storage.md о повторной попытке после получения keyId.
ADR-063: ACK уходил по одному на конверт, а не пачкой. Получатель в оживлённой
комнате выедал общее ведро подтверждениями и упирался в 429 на всех изменяющих
запросах, включая выход из комнаты: 116 отказов за прогон стало нулём.
ADR-055, 057, 060, 061, 062: ключи вёдер и границы, +dirty у bare version,
403 unknown_device не хоронит сообщение, усечение имени в подсказке ввода,
kdf как оракул после повышения цели KDF.

Модель угроз пополнена тем, что действительно видит оператор: push-подписки
лежат в базе открытым текстом, и вместе с VAPID-ключом с той же машины это
произвольное уведомление на экране блокировки.

README приведён к v1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DbCjVfTFq4ZFG8juD45YJ
2026-08-23 06:22:52 +03:00

3.8 KiB
Raw Permalink Blame History

ADR-042: Порядок ключей комнаты и «текущий ключ»

Уточняет ADR-018: «текущий ключ — последний полученный в порядке сервера».

Уточнён ADR-059: порядок относится ко всем удерживаемым ключам, а не только к последнему.

Контекст

На однозначности «последнего» держится обрезка: сервер хранит два последних keyId комнаты (ADR-018) и обязан не выбросить ничей действующий ключ. docs/storage.md определял его одной строкой — «строка room_keys с максимальным created_at», — а два rekey подряд укладываются в одну миллисекунду, и максимум становится неоднозначным.

Код этапа 3 это починил: сервер поднимает время нового ключа до последний + 1, а при равенстве доопределяет порядок по key_id; клиент делает то же со своим receivedAt. Инвариант несущий, а записан был только комментариями в коде.

Второе: порядка сервера клиент не знает и знать не может. В Room.key приходит один текущий ключ без номера и без времени, так что клиент считает текущим тот, который получил последним. В гонке двух rekey с разных устройств владельца эти порядки расходятся: устройство, чей ответ пришёл раньше события соседнего, считает текущим свой ключ, а сервер — чужой.

Решение

  • Инвариант записывается в docs/storage.md: время записи room_keys строго больше времени всех прежних ключей той же комнаты; при равенстве порядок доопределяется по key_id. То же — про клиентский roomKeys.receivedAt.
  • Клиент держит порядок получения, а не порядок сервера. Это осознанный предел: номера ключа в протоколе нет и не заводится.
  • Расхождение безвредно, пока оба ключа живы, а живы они, пока комната держит два последних keyId. Сообщение, отправленное ключом, который сервер уже обрезал, получает 400 unknown_key и хоронится как failed (ADR-033).

Следствия

  • Обрезка до двух keyId не выбрасывает ничей текущий ключ: самый свежий key_id есть у каждого участника (иначе keys_mismatch), и он остаётся всегда.
  • created_at в room_keys перестаёт быть в точности «миллисекундами Unix»: у двух rekey в одну миллисекунду второе время сдвинуто вперёд. Это записано рядом с колонкой.
  • Порядковый номер ключа в Room.key — возможное расширение отдельным ADR, если расхождение порядков когда-нибудь окажется дорогим.