MUMBLE "failed to get access using private key": чекер держит share-токен,
выданный ещё старым keygen, а после перехода на HMAC ValidateKey его
отвергал.
- keygen/legacy.go: восстановленный из keygen.a алгоритм
seed=(seed*17+42)%62 принимается ТОЛЬКО для video.id <= cutoff, то есть
для видео, существовавших на момент перехода. Выше cutoff -- лишь HMAC.
- cutoff берётся из max(video.id) при первом старте и пишется в
public/.legacy_cutoff на volume: рестарт не должен расширять окно.
Не смогли прочитать -- fail closed, legacy выключен.
- Когда старые флаги протухнут: echo 0 > public/.legacy_cutoff + рестарт,
и legacy отключается полностью.
Ещё MUMBLE "cannot create video" -- он же DoS, у NOP-команды то же самое:
- checkGeometry сделан FAIL-OPEN. Неразобранный ffprobe больше не отклоняет
загрузку, режем только успешно прочитанную и абсурдную геометрию.
- ffmpeg -max_alloc 128M: 1080p кадру нужно ~8 МБ, бомбе ~1 ГБ. Работает
даже когда probe промолчал.
check_tiktak.sh: smoke-тест для vulnbox, гоняет сценарий чекера целиком
и отдельно проверяет, что патчи реально в задеплоенном билде.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Share-токен приватного видео считался в legacy/keygen.a только от video id,
без ключа: seed=(seed*17+42)%62, out[i]=alpha[seed]. После первой итерации
состояние схлопывалось в id%62, то есть на весь сервис приходилось 62
различных токена. Разбирать бинарь не требовалось: 62 своих приватных видео
дают таблицу токенов ко всем чужим.
Форж токена => POST /access => строка в таблице access => haveAccess() отдаёт
и description, и субтитры, и .webm совершенно легально, мимо патча /vtt/.
Теперь HMAC-SHA256(secret, vid), те же сигнатуры и тот же 30-символьный
base62, cgo и keygen.a из сборки выпали (образ собирается под любую
архитектуру). Сверка constant-time через hmac.Equal.
Совместимость со старыми токенами намеренно не сохранена: раунды ещё не
начинались, приватных видео нет.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>