Two session-management bugs from the audit:
- /api/password recorded failed attempts against the login budget but never
checked it, so a borrowed session could guess the current password without
limit while still locking the owner out of /api/login. Verified: thirteen
consecutive wrong guesses all returned 403 and none returned 429. It now
spends from the same budget it was topping up.
- bump_epoch read the epoch and wrote it back without the write lock, so
concurrent revocations lost increments and sessions that should have been cut
off survived. Verified: twenty concurrent bumps advanced the counter from 2 to
6, and twenty concurrent "sign out other devices" calls left four sessions
authenticated. It takes BEGIN IMMEDIATE now; set_password hashes before
locking, so scrypt doesn't serialise unrelated writes.
Removing either fix makes its test fail with exactly that symptom.
README corrections: deployment is rsync, not git pull — gitea on .8 cannot
serve a clone to .8 itself, which the deploy section now documents — and the
concurrency check count was understated.
Checks go from 182 to 197.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
thejayman77
d76642f85d