fix(sirius-press): recovering a key is not the same as verifying a signature
Running the fork against a live WordPress found a real hole in registration,
and it is the kind that only shows up when you actually try it.
ECDSA public-key recovery always succeeds. Given any well-formed signature
and any digest it returns a key — just not the signer's, unless the digest is
the one that was signed. The auth flow leaned on that as if a wrong message
would fail. It does not; it quietly yields a stranger's address.
At sign-in this was harmless, because the wrong address matches no account
and the attempt fails. Registration and wallet-linking were another matter:
both took the recovered address and bound it to an account, so a signature
over slightly different text — a challenge copied without its blank line, a
wallet that rewrote the text, a login signature replayed at the registration
form — created an account keyed to an address nobody could sign for. The
person would see "success" and discover the truth the next time they tried to
get in. Wallet-linking was worse still: it would move an existing account onto
a dead address and lock its owner out of their own site.
Both paths now require the address the signer claims and compare it to the
recovered one, which is what verification actually means. Sign-in accepts the
claim when the page sends it and uses it to turn "no account uses that wallet"
into the more useful "that signature is not over the text we asked for".
Also from running it:
URL rewriting mangled every link on a site whose URL carries a port. The
protocol-relative pass matched inside absolute URLs and gave each one a second
scheme, and matching the host without its port left the port stranded as
`//host:8760:8760/`. Local and staging installs would have exported a site of
broken links.
Plain permalinks silently collapse an entire site onto one exported file,
because every post's URL is `/?p=N` and its path is `/`. The queue looks
healthy the whole time. The Publishing screen now says so.
Translations loaded on `plugins_loaded`, which WordPress 6.7 warns about on
every request — the kind of noise that trains people to stop reading logs.
And one deletion: an `is_email()` filter written on the assumption that
WordPress rejects `.invalid` addresses. It does not — `is_email()` validates
syntax, not whether a domain could exist — so the filter never fired. A filter
that appears to relax a rule but does not is worse than no filter, because
someone later reasons from it. The documentation made the same claim and has
been corrected.
Verification added rather than asserted: tests/live.mjs drives a real instance
over HTTP (40 checks), and tests/mock-gateway.mjs answers uploads with the
signature check transcribed from the gateway's own source, so the publishing
path can be exercised without a registered name.
2026-09-21 02:35:32 +02:00
|
|
|
# Testing
|
|
|
|
|
|
|
|
|
|
Four suites, in rough order of how fast they run and how much they prove.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
tests/run.sh # unit + interop, ~1 second, no services
|
|
|
|
|
node tests/live.mjs # end to end against a running instance
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## The fast suites
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
tests/run.sh
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Needs PHP 7.4+ with GMP or BCMath, and Node 18+. About a second, no database
|
|
|
|
|
and no server.
|
|
|
|
|
|
|
|
|
|
| Suite | Checks | What it pins |
|
|
|
|
|
|---|---|---|
|
|
|
|
|
| `test-crypto.php` | 23 | secp256k1 against published vectors, RFC 6979 determinism, low-S, recovery round trips |
|
|
|
|
|
| `test-identity.php` | 44 | CashAddress encode/decode/normalise, BIP-39/32 derivation, both signing envelopes, canonical JSON |
|
|
|
|
|
| `test-export.php` | 49 | URL-to-path mapping, document-relative rewriting, gateway path rules |
|
|
|
|
|
| `interop.mjs` | 22 | the browser wallet against the PHP one, byte for byte |
|
|
|
|
|
|
|
|
|
|
**`interop.mjs` is the one that matters most.** Sirius Press implements the
|
|
|
|
|
same cryptography twice — PHP verifies, JavaScript signs — and every vector in
|
|
|
|
|
that file came from libauth, the library the Sirius portal wallet and the BNS
|
|
|
|
|
gateway both use. If the two implementations disagree by a byte, nobody can
|
|
|
|
|
log in, and the error looks like a rejected password rather than a hash
|
|
|
|
|
mismatch. This suite makes that a test failure instead of a bad evening.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## A throwaway instance
|
|
|
|
|
|
|
|
|
|
You do not need Docker, MySQL or a VPS to run a real Sirius Press. PHP's
|
|
|
|
|
built-in server plus the official SQLite drop-in is enough, and it starts in
|
|
|
|
|
seconds.
|
|
|
|
|
|
|
|
|
|
```bash
|
build(sirius-press): build from the vendored subtree instead of a download
The subtree is in place, so everything that used to fetch and patch core at
build time now just copies it.
tools/build.sh copies wordpress/ — no download, no checksum step,
because there is nothing to fetch and nothing to
trust that is not already in the repository
docker/Dockerfile COPY wordpress/ instead of curl + sha256 + patch;
the build args and the `patch` package are gone
docker-compose.yml no WP_VERSION / WP_URL / WP_SHA256 to keep in step
tools/update-wordpress.sh is rewritten around what the subtree makes
possible. It imports the pristine release onto sirius-press/wordpress-upstream
and then `git subtree merge`s that branch, which three-way merges upstream
against the fork's own commit. A patch either applies with fuzz and hopes or
fails and leaves you re-deriving the change by hand; a merge conflict is
resolved once, in the file, and the next release merges against the
resolution.
patches/ survives as documentation rather than mechanism, and is now
generated: tools/refresh-patches.sh diffs the subtree against the pristine
import and rewrites the directory, with --check for CI. It answers the
question anyone auditing a fork asks first — what exactly did you change
inside WordPress? — in a minute, which `git log wordpress/` cannot, because
that log is mostly upstream imports. Generated documentation stays true; a
hand-maintained record of a core diff drifts, and a stale one is worse than
none because people trust it.
One test change worth noting: the syntax sweep no longer walks all of
wordpress/. It lints the fork's own PHP plus every core file patches/ says
the fork touches, which keeps the suite at seven seconds instead of a minute
while still covering the only core file that can break.
2026-09-21 03:19:28 +02:00
|
|
|
# 1. a complete tree (copied out of the vendored wordpress/, plugins added)
|
fix(sirius-press): recovering a key is not the same as verifying a signature
Running the fork against a live WordPress found a real hole in registration,
and it is the kind that only shows up when you actually try it.
ECDSA public-key recovery always succeeds. Given any well-formed signature
and any digest it returns a key — just not the signer's, unless the digest is
the one that was signed. The auth flow leaned on that as if a wrong message
would fail. It does not; it quietly yields a stranger's address.
At sign-in this was harmless, because the wrong address matches no account
and the attempt fails. Registration and wallet-linking were another matter:
both took the recovered address and bound it to an account, so a signature
over slightly different text — a challenge copied without its blank line, a
wallet that rewrote the text, a login signature replayed at the registration
form — created an account keyed to an address nobody could sign for. The
person would see "success" and discover the truth the next time they tried to
get in. Wallet-linking was worse still: it would move an existing account onto
a dead address and lock its owner out of their own site.
Both paths now require the address the signer claims and compare it to the
recovered one, which is what verification actually means. Sign-in accepts the
claim when the page sends it and uses it to turn "no account uses that wallet"
into the more useful "that signature is not over the text we asked for".
Also from running it:
URL rewriting mangled every link on a site whose URL carries a port. The
protocol-relative pass matched inside absolute URLs and gave each one a second
scheme, and matching the host without its port left the port stranded as
`//host:8760:8760/`. Local and staging installs would have exported a site of
broken links.
Plain permalinks silently collapse an entire site onto one exported file,
because every post's URL is `/?p=N` and its path is `/`. The queue looks
healthy the whole time. The Publishing screen now says so.
Translations loaded on `plugins_loaded`, which WordPress 6.7 warns about on
every request — the kind of noise that trains people to stop reading logs.
And one deletion: an `is_email()` filter written on the assumption that
WordPress rejects `.invalid` addresses. It does not — `is_email()` validates
syntax, not whether a domain could exist — so the filter never fired. A filter
that appears to relax a rule but does not is worse than no filter, because
someone later reasons from it. The documentation made the same claim and has
been corrected.
Verification added rather than asserted: tests/live.mjs drives a real instance
over HTTP (40 checks), and tests/mock-gateway.mjs answers uploads with the
signature check transcribed from the gateway's own source, so the publishing
path can be exercised without a registered name.
2026-09-21 02:35:32 +02:00
|
|
|
tools/build.sh
|
|
|
|
|
cp -R dist/sirius-press /tmp/wpsite
|
|
|
|
|
|
|
|
|
|
# 2. SQLite instead of MySQL
|
|
|
|
|
curl -fsSL -o /tmp/sqlite.zip \
|
|
|
|
|
https://downloads.wordpress.org/plugin/sqlite-database-integration.zip
|
|
|
|
|
unzip -q /tmp/sqlite.zip -d /tmp/wpsite/wp-content/plugins/
|
|
|
|
|
cp /tmp/wpsite/wp-content/plugins/sqlite-database-integration/db.copy \
|
|
|
|
|
/tmp/wpsite/wp-content/db.php
|
|
|
|
|
mkdir -p /tmp/wpsite/wp-content/database
|
|
|
|
|
|
|
|
|
|
# 3. a config (any salts will do for a throwaway)
|
|
|
|
|
cp /tmp/wpsite/wp-config-sample.php /tmp/wpsite/wp-config.php
|
|
|
|
|
# edit it: DB_* values are ignored by the SQLite drop-in, but add
|
|
|
|
|
# define( 'WP_HOME', 'http://127.0.0.1:8760' );
|
|
|
|
|
# define( 'WP_SITEURL', 'http://127.0.0.1:8760' );
|
|
|
|
|
|
|
|
|
|
# 4. run it
|
|
|
|
|
php -S 127.0.0.1:8760 -t /tmp/wpsite
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Then open `http://127.0.0.1:8760/wp-admin/install.php`. The setup screen asks
|
|
|
|
|
for a wallet address instead of an email one — that alone confirms the core
|
|
|
|
|
patch applied.
|
|
|
|
|
|
|
|
|
|
PHP needs `pdo_sqlite`, `sqlite3`, `gd`, `mbstring` and one of GMP or BCMath.
|
|
|
|
|
|
|
|
|
|
**Set pretty permalinks before testing publishing.** With plain permalinks
|
|
|
|
|
every post's URL is `/?p=N`, whose path is `/`, so the whole site maps to
|
|
|
|
|
`index.html` and each page overwrites the last. The Publishing screen refuses
|
|
|
|
|
to let this pass quietly, but a script driving the queue directly will not see
|
|
|
|
|
the warning.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## End to end
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
WALLET=/tmp/admin-wallet.json BASE=http://127.0.0.1:8760 node tests/live.mjs
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
`WALLET` is a JSON file holding an administrator's phrase and address:
|
|
|
|
|
|
|
|
|
|
```json
|
|
|
|
|
{ "phrase": "twelve words …", "address": "bchtest:qq…" }
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
40 checks covering sign-in, replay refusal, a stranger's signature, a
|
|
|
|
|
signature over altered text, purpose separation, registration, the recovery
|
|
|
|
|
page and the REST endpoints — against a real WordPress, with real sessions.
|
|
|
|
|
|
|
|
|
|
It creates one account per run, so point it at a throwaway.
|
|
|
|
|
|
|
|
|
|
### Running it with the ecosystem loaded
|
|
|
|
|
|
|
|
|
|
The suite is worth far more with third-party plugins active, because it then
|
|
|
|
|
also proves the fork's admin screens survive them:
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
for p in wordpress-seo contact-form-7 woocommerce; do
|
|
|
|
|
curl -fsSL -o "/tmp/$p.zip" "https://downloads.wordpress.org/plugin/$p.zip"
|
|
|
|
|
unzip -q -o "/tmp/$p.zip" -d /tmp/wpsite/wp-content/plugins/
|
|
|
|
|
done
|
|
|
|
|
# activate them, then re-run tests/live.mjs
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
If you hit a 429, the rate limiter is doing its job — it caps signature
|
|
|
|
|
verification per client. Clear it between runs:
|
|
|
|
|
|
|
|
|
|
```sql
|
|
|
|
|
DELETE FROM wp_options WHERE option_name LIKE '%_transient_%sirius_rl_%';
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## Publishing, without a registered name
|
|
|
|
|
|
|
|
|
|
The upload path cannot be tested end to end without a BCNR name and the key
|
|
|
|
|
that owns it. What *can* be tested is the part that actually breaks — the
|
|
|
|
|
bytes being signed — against the real verifier:
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
node tests/mock-gateway.mjs --owner bchtest:qq… --port 8799
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This implements `PUT /api/site/<name>/<path>` with the signature check
|
|
|
|
|
transcribed from `Argus/src/gateway/public-gateway.mjs`: same envelope, same
|
|
|
|
|
digest, same recovery, same comparison against the owner. A request it accepts
|
|
|
|
|
is one the real gateway accepts.
|
|
|
|
|
|
|
|
|
|
Point the site at it — **Sirius Press → Settings**, gateway
|
|
|
|
|
`http://127.0.0.1:8799` — store the matching phrase, publish a post, and watch
|
|
|
|
|
the queue drain. Signing with any other key gets the same 403 the real gateway
|
|
|
|
|
returns.
|
|
|
|
|
|
|
|
|
|
It needs `@bitauth/libauth` resolvable from the script, which is the point: it
|
|
|
|
|
verifies with the same library the gateway does, not with ours.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
2026-09-22 20:19:42 +02:00
|
|
|
## In a browser
|
|
|
|
|
|
|
|
|
|
Everything above drives the site over HTTP, which is fast and repeatable and
|
|
|
|
|
misses a whole class of bug. Two got through it and were only found by opening
|
|
|
|
|
`wp-login.php` in a browser and clicking the button:
|
|
|
|
|
|
|
|
|
|
- WordPress marks its username and password inputs `required`. The wallet path
|
|
|
|
|
leaves both empty on purpose, so `requestSubmit()` failed constraint
|
|
|
|
|
validation and refused to send a perfectly good signature — with a bubble
|
|
|
|
|
pointing at a field the visitor is not meant to fill in.
|
|
|
|
|
- The `hidden` attribute does not survive WordPress's own stylesheet.
|
|
|
|
|
`.wp-core-ui .button { display: inline-block }` outranks the UA rule that
|
|
|
|
|
makes `hidden` work, so buttons this plugin ships hidden were on screen
|
|
|
|
|
anyway, inverting the progressive-enhancement design.
|
|
|
|
|
|
|
|
|
|
So: **after changing anything in `plugins/sirius-press-auth/assets/`, open the
|
|
|
|
|
login page and click the button.** The HTTP suites will not tell you.
|
|
|
|
|
|
|
|
|
|
Serve the throwaway instance and point a browser at
|
|
|
|
|
`http://127.0.0.1:8760/wp-login.php`. `127.0.0.1` counts as a secure context,
|
|
|
|
|
so WebCrypto works over plain HTTP there — on any other host the in-page
|
|
|
|
|
wallet needs real HTTPS, and the script says so and falls back to the paste
|
|
|
|
|
box.
|
|
|
|
|
|
|
|
|
|
Worth checking by hand, in this order: the sign-in button appears, the
|
|
|
|
|
browser-wallet button does *not* (unless you are in Theseus), typing the
|
|
|
|
|
phrase and clicking signs and lands you on the dashboard, and the challenge
|
|
|
|
|
text in the box matches what your wallet shows you.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
fix(sirius-press): recovering a key is not the same as verifying a signature
Running the fork against a live WordPress found a real hole in registration,
and it is the kind that only shows up when you actually try it.
ECDSA public-key recovery always succeeds. Given any well-formed signature
and any digest it returns a key — just not the signer's, unless the digest is
the one that was signed. The auth flow leaned on that as if a wrong message
would fail. It does not; it quietly yields a stranger's address.
At sign-in this was harmless, because the wrong address matches no account
and the attempt fails. Registration and wallet-linking were another matter:
both took the recovered address and bound it to an account, so a signature
over slightly different text — a challenge copied without its blank line, a
wallet that rewrote the text, a login signature replayed at the registration
form — created an account keyed to an address nobody could sign for. The
person would see "success" and discover the truth the next time they tried to
get in. Wallet-linking was worse still: it would move an existing account onto
a dead address and lock its owner out of their own site.
Both paths now require the address the signer claims and compare it to the
recovered one, which is what verification actually means. Sign-in accepts the
claim when the page sends it and uses it to turn "no account uses that wallet"
into the more useful "that signature is not over the text we asked for".
Also from running it:
URL rewriting mangled every link on a site whose URL carries a port. The
protocol-relative pass matched inside absolute URLs and gave each one a second
scheme, and matching the host without its port left the port stranded as
`//host:8760:8760/`. Local and staging installs would have exported a site of
broken links.
Plain permalinks silently collapse an entire site onto one exported file,
because every post's URL is `/?p=N` and its path is `/`. The queue looks
healthy the whole time. The Publishing screen now says so.
Translations loaded on `plugins_loaded`, which WordPress 6.7 warns about on
every request — the kind of noise that trains people to stop reading logs.
And one deletion: an `is_email()` filter written on the assumption that
WordPress rejects `.invalid` addresses. It does not — `is_email()` validates
syntax, not whether a domain could exist — so the filter never fired. A filter
that appears to relax a rule but does not is worse than no filter, because
someone later reasons from it. The documentation made the same claim and has
been corrected.
Verification added rather than asserted: tests/live.mjs drives a real instance
over HTTP (40 checks), and tests/mock-gateway.mjs answers uploads with the
signature check transcribed from the gateway's own source, so the publishing
path can be exercised without a registered name.
2026-09-21 02:35:32 +02:00
|
|
|
## What is not covered
|
|
|
|
|
|
fix(sirius-press): the exporter could never reach its own site in Docker
Deployed to a real VPS for the first time. The stack came up, the patched
wizard served, the plugins activated and the 40-check auth suite passed over
the public internet — and then every single export failed:
cURL error 28: Failed to connect to <public ip> port 8081 after 10001 ms
Not a bug in the export. A container cannot reach the host's own published
port on most Docker hosts; there is simply no route back in. The exporter
renders each page by asking the site for it over HTTP, so the one thing it
depends on is the one thing a container cannot do. This would have hit every
user of the documented install path on their first publish, and the error
says nothing about the cause.
SIRIUS_PRESS_LOOPBACK_URL gives the exporter a second address — in the
bundled stack, the nginx service on the compose network — while the request
still carries the site's real Host header. That matters twice: WordPress
renders exactly the page a visitor gets rather than redirecting to a
canonical URL the container cannot follow, and the internal hostname never
appears in the exported HTML. Verified on the VPS: the page builds, the
content is right, no absolute self-links, no `//web/` leaking out.
Also documents the question underneath it — what WP_HOME should be when the
site's public address is a BCNR name. Not the name: whatever the server is
actually reachable at. The exported links are document-relative, so they work
under the name regardless.
2026-09-22 22:43:30 +02:00
|
|
|
- **A real gateway upload.** The signing is verified against the transcribed
|
|
|
|
|
verifier above, and against the real gateway's answer about who owns a name,
|
|
|
|
|
but no byte has yet been written to `navigate.st` under a registered name.
|
2026-09-22 20:19:42 +02:00
|
|
|
- **Manual-mode publishing in a browser.** The server-signing path is
|
|
|
|
|
exercised end to end; the browser-signs-and-uploads path in
|
|
|
|
|
`assets/export.js` has not been clicked through.
|