sirius-press/CHANGELOG.md
Local Dev 373394b534 sirius-press: a site with passwords off could not be signed into
Three faults, all on the same screen, all only visible once passwords
were actually turned off — which until now nobody had done on a live
instance.

wp-login.php runs wp_signon() on its way to drawing the form, even for a
plain GET. Core tolerates that by discarding the result, but only when
the error codes are exactly the pair its own password filters produce.
Removing those filters is the whole point of turning passwords off, so
what was left behind was the generic authentication_failed — printed, in
red, above a form with no username and no password, on a site that has
neither. Every visitor was told their sign-in had failed before they
tried.

The paste-a-signature path had no way to submit. It borrowed core's
login button, and the stylesheet that retires the password form hid that
button too. The one route for people whose keys live on another machine
— sign in Electron Cash, paste the result — was therefore broken exactly
on the sites most committed to not having passwords. It now carries its
own plain submit button, so it also works on the screens where there is
no core login form to borrow from, and with JavaScript off.

And the username field outlived the password field, although
authenticate() never reads it either. "Username or Email Address" sat at
the top of a wallet login form: the one thing this fork exists to
remove, in the first place anyone looks. Both go now, with their
required attributes cleared, because a hidden required field does not
fail quietly — it refuses the submit and points an error bubble at a
control nobody can see.
2026-10-03 00:57:34 +02:00

159 lines
8.3 KiB
Markdown

# Changelog
## 0.1.0 — unreleased
First cut. Sirius Press installs, signs people in with a wallet, and publishes
static copies of its pages to a BCNR name.
### Accounts
- Sign in by signing a challenge with a Bitcoin Cash key. The address is
recovered from the signature, so nothing has to be typed but the signature
itself.
- Three ways to produce one: a wallet the browser already exposes (Theseus), a
recovery phrase used once in the page and wiped, or a signature pasted in
from any BIP-137 wallet. The last works with JavaScript disabled.
- One-step registration — the signature is the confirmation, so there is no
email round trip and no pending state.
- Password sign-in stays on by default and can be turned off once every
account has a wallet. The screen that turns it off refuses to do so while it
would lock out the person asking.
- No password reset, and the "lost password" page explains why rather than
pretending otherwise.
- `/sirius-press/v1/confirm` lets any plugin demand a fresh signature before
something irreversible.
### Publishing
- Publishing a post exports it, the home page and its archives to the name's
storage on Sia, signed BNS-SITE1.
- Two signing modes: manual, where the browser signs and the server stores
nothing, and automatic, where an encrypted phrase lets cron publish alone.
Manual is the default.
- Unchanged pages are hashed and skipped rather than re-uploaded.
- Unpublishing a post removes its file from the mirror.
- `wp sirius export` and `wp sirius status` for the command line.
### Compatibility
- Every account carries an unroutable `.invalid` placeholder `user_email`, so
the thousands of ecosystem reads of that field keep returning a string.
- Mail to those placeholders is captured into an in-app inbox. Mail to real
addresses is passed through untouched, so SMTP works normally.
- Shims for WooCommerce, Contact Form 7 and core's admin-email machinery.
### Core
- One change, 75 lines, in `wp-admin/install.php`: the setup wizard asks for a
wallet address instead of an email address, and the address is optional.
- WordPress is vendored at `wordpress/` as a git subtree, already patched.
Upstream releases arrive through `git subtree merge` against
`sirius-press/wordpress-upstream`, a branch of pristine imports, so a
release that touches code near the fork's change is three-way merged rather
than re-derived by hand. `tools/update-wordpress.sh <version>` runs the
whole thing.
- `patches/` is now generated from the tree by `tools/refresh-patches.sh`
(with `--check` for CI) and exists to answer "what does this fork change in
core?" without reading a 3,800-file log. It is documentation, not the build
mechanism.
### Packaging
- `install.sh` for a fresh Ubuntu VPS; Docker stack with MariaDB, PHP-FPM and
nginx. Core lives in the image, so rebuilding is a real upgrade.
- `tools/build.sh --zip` for shared hosting.
- `tools/update-wordpress.sh` to move onto a new upstream release.
- `tools/publish-release.sh` to ship to both mirrors.
### Fixed while testing against a live instance
- **Registration and wallet-linking accepted a signature over the wrong text.**
Public-key recovery always succeeds — it returns a different key rather than
failing — so a mismatched signature silently bound an account to an address
nobody could sign for. Both paths now require the claimed address and
compare it to the recovered one. Sign-in was never exposed to this, because
a wrong address simply matches no account.
- URL rewriting mangled links on any site whose URL carries a port: the
protocol-relative pass matched inside absolute URLs and doubled the scheme,
and a host-only match left the port stranded. Both covered by tests now.
- Translations loaded on `plugins_loaded`, which WordPress 6.7+ warns about on
every request. Moved to `init`.
- The Publishing screen now refuses to be quiet about plain permalinks, which
would collapse an entire site onto one exported file.
- Removed an `is_email()` filter that rested on a false premise: WordPress
validates syntax, not whether a domain can exist, so `.invalid` addresses
already pass and the filter never fired. The documentation said otherwise
and has been corrected.
### Fixed after opening it in a browser
- Wallet sign-in did not work in a browser at all. WordPress marks its
username and password inputs `required`; the wallet path leaves both empty
on purpose, so the form refused to submit a valid signature and pointed a
validation bubble at a field the visitor is not meant to fill in.
- The `hidden` attribute was being overridden by WordPress's own button
styles, so controls this plugin ships hidden were visible regardless —
offering a browser wallet that is not there, and showing a JavaScript-only
button to visitors without JavaScript.
### WordPress 7.1.2
Taken through `tools/update-wordpress.sh` and merged cleanly; upstream did not
touch the one file this fork patches. Two bugs in the update tool surfaced
doing it: a Windows path-subtraction that produced an absolute `--prefix`, and
git-subtree's refusal to run in a repository with any uncommitted file. The
merge now runs in a scratch worktree and a failed run can be retried.
### Fixed after deploying to a real VPS
- **Static export could never work in the bundled Docker stack.** The exporter
fetches each page over HTTP, and a container cannot reach the host's own
published port on most Docker hosts — every export died with a cURL
timeout while the site itself was plainly up. `SIRIUS_PRESS_LOOPBACK_URL`
now points the exporter at the nginx service on the compose network, with
the site's real `Host` header so the rendered page is unchanged and the
internal address never reaches the output. The stack sets it by default.
### Fixed while building a real site on it
- **Turning passwords off made the login screen fail on arrival.**
`wp-login.php` calls `wp_signon()` on its way to drawing the form, even for
a plain GET, and core throws the result away only when the error codes are
exactly the pair its own password filters produce. Removing those filters —
which is the entire point of turning passwords off — left the generic
`authentication_failed` behind, so every visitor met a red "Invalid
username, email address or incorrect password" above a form with neither
field, on a site with no passwords.
- **The paste-a-signature path had no way to submit.** It borrowed core's
login button, and the stylesheet that retires the password form was hiding
that button along with it. So the one route meant for people whose keys live
on another machine — sign in Electron Cash, paste the result — was a dead
end precisely on the sites most likely to need it. It now carries its own
submit button, which also makes the block work on the screens where there is
no core login form to borrow from.
- **The username field outlived the password field.** With passwords off,
`authenticate()` never reads the username either, yet "Username or Email
Address" stayed at the top of the form — the exact thing this fork exists to
remove, in the first position a visitor looks. Both fields are now retired
together, and their `required` attributes are cleared so a hidden field
cannot silently refuse a submit.
- **The image had no wp-cli.** `docs/publishing.md` documents
`wp sirius export` and `wp sirius status`, and the export plugin registers
both — on a stack built from `docker/`, neither existed. wp-cli is now in
the image, pinned to a version and checked against its SHA-256; it is the
only thing the build fetches, which is why it is the only thing that has to
prove what it is.
### Known gaps
- No byte has yet been written to the real gateway under a registered name.
The signing is verified against a transcription of the gateway's own
verifier, and the live instance reads the correct on-chain owner from
`navigate.st`, but the upload itself is untested.
- Manual-mode publishing (browser signs and uploads) has not been clicked
through; the server-signing path has.
- Publishing is verified against a transcription of the gateway's own
verification logic, not against `navigate.st` with a registered name.
- Seven of the ten rows in the plugin compatibility matrix are reasoned rather
than tested; the three named in the ship criteria were installed and run.