Esta página só existe em inglês. O menu e os outros textos seguem em português.

Security upgrade notes

This update tightens identity checks and retained-site quotas. Review existing identities before restarting the gateway. Back up the gateway database and stop gateway writes while performing any identity repair. Keep backups private.

The WordPress identity binding and the wp-cli command policy that were part of this update went away with the WordPress lane in 0.10.0; the wp_identities table and the users.wp_login column stay in older databases, unread.

GitHub identities

Accounts are matched by positive numeric GitHub ID. A username change preserves the local account when the new username is free; a conflicting username is refused. A different GitHub ID cannot take over an existing local username. Existing accounts cannot receive another invitation; obsolete invitations for the old and current usernames are cleared during verified login/rename.

Legacy accounts created by offline bootstrap may have no GitHub ID. Their existing tokens continue to work, but GitHub login is refused until the operator explicitly binds the account after independently verifying its owner. Matching a current username alone is not enough. Never clear an ID to make login succeed. After stopping the gateway and taking a consistent SQLite backup (including any WAL state), use bound SQL parameters for the verified positive ID and local row:

SQL

BEGIN IMMEDIATE;
UPDATE users SET github_id = :verified_id
WHERE id = :local_id AND COALESCE(github_id, 0) = 0
  AND :verified_id > 0
  AND NOT EXISTS (SELECT 1 FROM users WHERE github_id = :verified_id);
SELECT changes();

Commit only if exactly one row changed and the read-back identity is correct; otherwise roll back. Do not substitute a guessed ID or infer ownership from a username. If earlier token issuance is suspect, revoke the affected tokens before resuming access.

The configured bootstrap username can create the first owner only when no local owner exists; it does not bind or promote an existing account.

Startup adds a unique index for positive GitHub IDs. If old records contain duplicates, startup fails instead of choosing an account. Preserve the database, verify which local account owns each identity and its sites, revoke any tokens issued to a wrongly linked account, and reconcile the conflicting records before restart. To quarantine conflicting rows, disable every affected account and clear its provider binding to zero while retaining its local ID, role, sites, and history. Rebind only independently verified, distinct provider IDs with the conditional transaction above. Leave unverified rows disabled and unbound. Do not pick a winner by row order, delete accounts, or transfer sites merely to make the index succeed. Re-enable a quarantined account only after verification and token review.

Operation changes

Deleted or archived sites count toward the quota while their data is retained. An owner purge releases the slot; a soft delete does not. Creation reserves capacity atomically, including concurrent requests.
Owner mutations require a token with publish scope. Read-only owner tokens retain read access and can revoke themselves by logging out.
Artisan commands on the Laravel lane are audited with passwords and secrets in flags redacted. Older audit records are not scrubbed by this update; if earlier records contain credentials, restrict access and rotate those credentials using the relevant account's controls.

Installer verification

The installer verifies the exact platform binary against SHA256SUMS before replacing an installed executable. RAPADURA_SHA256 optionally pins a digest verified through an independent channel. Binary and manifest downloads require HTTPS. A manifest served by the same host detects mismatched downloads but does not establish authenticity against compromise of that host or installer.

Regression checks

shell

go test ./...
go test -race ./...
go vet ./...
sh -n deploy/install.sh
bash -n deploy/rapadura-artisan
bash -n deploy/install-vm.sh

Tests use temporary SQLite databases, dry-run hosting, a fake artisan runner and controlled installer downloads. They do not reproduce the production systemd/sudo environment; verify that and operator identity migrations in staging before a production rollout.