basaltd 0.9.1

basaltd 0.9.1

Upgrade if you run basaltd 0.9.0 or earlier. This release fixes four server defects, one of which could send a note to a device you had just revoked. Your devices need no update: protocol 7 and the data format are unchanged, and every Basalt client from 0.8.0 on, including the 0.9.0 plugin, keeps working exactly as it does against 0.9.0.

What is fixed

A revoked device could still be sent a note. When you revoked a device, a note another device saved in the moment between the revoke taking effect and the revoked device's connection closing could still be delivered to it, and a Basalt device holds the key to read what it is sent. The same was true of a device unlinking itself, and of a revoked device still catching up on a backlog, which could read notes saved after the revoke. The revoked device's connections now leave delivery in the same step that removes the device, and the only thing they hear afterwards is the notice that they were revoked. The revoke itself, and every other device, behave as before.

A batched commit could still fail with disk I/O error (6410). 0.8.5 told SQLite to keep its temporary files in memory, which the read-only container needs because it has no temporary directory, but the setting only ever reached one of the server's database connections. Every connection now gets it, including the read-only ones verify, stats and backup inspection use. The one-entry-at-a-time fallback added in 0.8.5 stays, so even before this fix such a failure slowed a vault rather than stopping it.

The name of the vault this server serves was visible to anyone who could reach the port. A connection naming any other vault was refused with a message naming the one served, and a malformed pairing attempt was answered differently for the served vault than for any other. Both now get the same refusal a wrong credential gets. The server's log still records which vault was asked for and which is served.

Invalid text in a request was silently changed. A request carrying invalid UTF-8, or half of a UTF-16 surrogate pair, had those characters replaced with U+FFFD, so a device name, for example, was stored as something other than what was sent, and the device was told it had worked. Such a request is now refused and the connection closed. No Basalt client sends one.

What you might notice

A connection that names the wrong vault, for example from a mistyped setup line, is now told "not authorised for this vault", like any other credential failure, rather than which vault the server serves. The server log says both.

Upgrading

Use ghcr.io/waynehoover/basalt-sync:0.9.1, preferably pinned to its published digest, or the matching binary below. Stop the previous server cleanly and keep the existing data directory, ownership and configuration: nothing in the data directory changes, no migration runs, and no device needs re-pairing.

Verification and limits

Every fix has a regression test that fails on 0.9.0 and passes here, and the release checks include the server's race tests, a backup and restore rehearsal, protocol integration tests and execution of both published container architectures. Process termination tests do not simulate power loss. Existing local-filesystem and trusted-device assumptions remain; network filesystems are unsupported.

Verify the downloaded files and their provenance:

shasum -a 256 -c SHA256SUMS
gh attestation verify basaltd-linux-amd64 --repo waynehoover/basalt-sync