The rule said one approving review. On a four-person team where the author is
usually the only person awake, that meant every merge went through
`gh pr merge --admin` — so the requirement was not producing review, it was
producing a habit of bypassing the branch rule. A control everyone routes around
is worse than no control: it still shows up green in an audit.
Zero required approvals, and the rest of the protection stays exactly as it was.
Nothing lands on main without a PR; nothing merges with red CI. That is the part
a team this size actually gets value from, and it costs no waiting.
What was being protected here was never code review. It was that nothing reaches
production unnoticed, and that funds cannot move on one person's say-so. Both
live elsewhere: production waits on the environment gate, and fund movement is
going behind on-chain multisig — where a stolen account cannot forge a second
signature the way a collected token can forge a second approval.
Drift check passes against live settings.
Driving the real login page in a browser showed what shipping this actually
looks like when Cloudflare decides a visitor must click: the submit button sits
on 'Signing in...' while an unnoticed 'Verify you are human' checkbox waits in
the bottom-right corner. Nothing tells the user it is there. They conclude login
is broken, and they are not wrong.
Two changes:
- The challenge is centred over a dimmed backdrop while it is visible, and
returns to the corner once answered. Detected by measuring the container
rather than by Turnstile's interactive callbacks: those callbacks are not in
the documentation this was written against, and a callback name that turns out
to be wrong fails silently — leaving the challenge in the corner, which is the
bug being fixed.
- A 90 second cap on waiting for a token. Without it, a challenge nobody answers
leaves the button spinning forever with no error and no way back. Every caller
already surfaces a rejection to the user.
The ResizeObserver fallback polls instead of returning a no-op. Doing nothing
there would restore the original bug on those browsers and do it without an
error, which is the worst way for a fix to be missing.
Signup had no bot protection. The account itself was never the prize — GoTrue
refuses a session until the address is confirmed, and 0 of the 2 unconfirmed
accounts on record ever signed in. The prize is our mail: /signup and /recover
send to whatever address the caller types, so a stranger could make
pezkuwichain.io mail thousands of people who never asked for it. Sending
reputation takes months to rebuild and every product on the domain shares it.
Rate limiting alone was not enough. GoTrue defaults to 30 emails/hour, which is
720 a day to attacker-chosen recipients; tightening it to 15 halves the number
without changing what is possible.
Verification runs inside GoTrue, not here. It POSTs to siteverify with the
widget secret before /signup, /recover, /resend, /magiclink, /otp and /token
with grant_type=password. Adding our own check in the frontend or a proxy would
protect nothing, because /auth/v1/signup is reachable directly.
One shared widget in execute mode rather than one per form: some of these are
buttons with nowhere to put a checkbox, and interaction-only appearance keeps
the challenge invisible unless Cloudflare asks for one. Tokens are single-use,
so each call renders fresh and tears down the previous widget.
Six call sites, matching the six protected endpoints — password login included,
since /token with grant_type=password is enforced. Refresh-token grants are
exempt, so open sessions are unaffected.
Site key travels as a build arg like the WalletConnect id: it is public by
construction, visible in the bundle. Only the secret is privileged and it lives
in GoTrue's env on the auth host.
Ships ahead of enforcement. Turning captcha on server-side before the frontend
sends tokens would break every login and signup in the same instant.
Moving approval to a GitHub Environment fixed the failure it was meant to fix,
and quietly broke something that worked. The old gate polled a file for 30
minutes holding a runner; on 2026-07-30 the window expired unseen and cancelled
a deploy. What replaced it holds the run for 30 days on no runner and records
who approved which SHA — but only answers to a browser. For a single approver
that means being at a PC for a deploy to move.
The notification now carries Approve and Reject buttons that answer the
environment's pending deployment through @pexsecBot. Nothing about the
enforcement changes: the protection rule still holds the deploy, and the bot
only presses the button as the reviewer. If the bot, its host, or its token is
gone, a release waits — none of that lets an unapproved deploy through. The
GitHub link stays as the fallback.
Bot side: pezkuwichain/pexsec-bot (new private repo — it had been an
unversioned copy on NEW-10 with three .bak files beside it).
SatoshiQaziMuhammed