painfree 0.2.0
Seven findings from the first real deployment, fixed, plus the custody secret
said where it matters.
Upgrading from 0.1.0
Two changes need a decision rather than a restart.
The state moved from named volumes to bind mounts under state/. That is
the fix for down -v deleting the sealed EBICS keys. An existing deployment
does not migrate itself: take a deploy/snapshot.sh before you upgrade, bring
the new stack up, and restore into it.
Generating a connection's first keys is now refused until somebody confirms
a copy of the custody secret exists, on /ui/recovery. Existing connections are
unaffected: their keys are already sealed, and the confirmation would not make
them safer. Take the copy with the new deploy/backup-secrets.sh.
Fixed
podman-compose down -vno longer destroys the database, and with it every
sealed EBICS private key. No compose command can remove a bind mount.- The shipped ports work under a rootless engine: loopback and above 1024 by
default, and the proxy takes its ports from.env, so the site address never
has to carry one. .localhostneeds an/etc/hostsline under glibc, and now says so.- The local CA's root is served at
/local-ca.crt, unauthenticated, so a
browser can be taught to trust a.localhostdeployment. deploy/snapshot.shdumps the database from inside the container that can
read it, instead of atarthat silently skips it.POST /v1/connectionsregisters a bank connection over the JSON API, behind
the sameconnections:writethe console route checks.
Added
/ui/recovery: which custody key this deployment's keys are sealed under,
where the file is, and a downloadable card. No secret is on that page and none
can be: the process serving it is refused the custody secret.deploy/backup-secrets.sh: the archive that makes a host recoverable. It
excludes the database on purpose, because an archive holding both the key and
the data it opens is a safe with its combination taped to the door.PAINFREE_OIDC_ADMIN_ROLEandPAINFREE_OIDC_MEMBER_ROLE: what your
directory calls these, comma-separated. The defaults are the names 0.1.0
accepted, so nothing changes on upgrade, and both resolved values appear in
theservice.startingline.
Status
Early. Not in production, and not suitable for anyone else's money. No real bank
has seen this.