jwinterm
5df12d3df8
From a 5-lens adversarial review of the admin surface (6 confirmed findings,
collapsing to 4 fixes; 2 dismissed after verification):
- HIGH: last-key-revoke TOCTOU (lockout). The count(live)<=1 floor was checked in
the handler, then revoke ran separately — two concurrent revokes could both pass
and empty the allowlist. Moved the floor INTO revoke_admin_key_full under a
per-tx advisory lock (admin_keys_mutate_lock); returns RevokeKeyOutcome
{Revoked,NotFound,WouldEmptyAllowlist}.
- LOW: ADMIN_MAX_KEYS cap TOCTOU. Same check-then-mutate race on add. Cap is now
counted INSIDE create_admin_key_audited under the same lock; returns
AddKeyOutcome {Created,CapReached}. rotate takes the lock too, so all
add/revoke/rotate serialize.
- LOW: integrity MAC didn't cover activation_deadline — a DB-write attacker could
null/extend the deadline to revive an expired pending key without breaking the
MAC. Added activation_deadline to AdminKeyMacInput + the canonical input +
every compute/verify site; new KAT binds it.
- LOW: get_active_admin_key (and create_*) logged the full pubkey via #[instrument]
(params weren't skipped), defeating the prefix-only / no-social-graph design.
Skipped pubkey/input from those spans.
Dismissed (both skeptics not-a-bug): audit-chain JSONB `details` round-trip — the
handlers always pass details:None and serde's sorted-key default makes the
string case round-trip (the L1 chain test proves it). Documented v1 deferrals
(login timing-oracle hardening, per-pubkey backoff, hard non-loopback bind guard)
remain tracked, not regressions.
All gates green: 138 lib + 138 integration, no openapi drift, secret-scan, leak.
smirk-backend-core
Open, self-hostable backend for the Smirk non-custodial, multi-chain wallet. It provides the chain-access and identity surface a Smirk wallet needs — authentication, per-chain wallet access (Bitcoin, Litecoin, Monero, Wownero, Grin), the Grin slatepack relay, and Nostr-based identity — so anyone can run their own backend and a Smirk wallet can connect to it.
Status: early, under active development. Interfaces and the database schema may change before the first tagged release. Not yet recommended for production self-hosting.
What it is
- Non-custodial. The server never holds spend keys or seeds. It brokers access to blockchain data and relays wallet-to-wallet messages.
- Open core, feature-flagged. Every feature ships in this codebase and is
toggled per deployment; the wallet reads
GET /api/v1/capabilitiesand adapts to what a given backend offers. - Identity via "Sign in with Smirk". Authentication uses a seed-derived Nostr key (NIP-98); the server stores only public keys.
- Privacy first. No PII is required to use it; operator and user privacy are explicit design goals.
Architecture
Rust + Axum, PostgreSQL via sqlx. The public HTTP contract is generated from the handlers with utoipa (OpenAPI), which in turn drives the wallet's generated TypeScript client — one source of truth, checked for drift in CI.
Quickstart
cp .env.example .env # then fill in DATABASE_URL, JWT_SECRET, node URLs
cargo run # starts the API server
A full self-hosting guide (node requirements, reverse proxy, Tor admin onion,
backups) will live in docs/ as it stabilises.
Security
Please report vulnerabilities privately — see SECURITY.md. Do not open public issues for security reports.
License
To be finalized (MIT vs AGPL-3.0-or-later). Until a LICENSE file is added,
all rights are reserved.