Vault Manager v0.7.3

Vault Manager v0.7.3

If your saved list of nodes ever goes missing, Vault Manager now says so instead of quietly
welcoming you as a new user. Until this release, a node list that had vanished looked exactly like
a computer that had never set one up — the same cheerful "add your first node" screen, with nothing
to suggest anything had been lost.

Who this affects

Nobody's node, and nobody's data. This is about Vault Manager's own record — the small file on your
computer that remembers which nodes you have paired with and holds the credential for them. Your
node keeps running exactly as before, and nothing on it is touched.

If your list is intact, this release changes nothing you will see.

What was wrong

Vault Manager already knew the difference between "I cannot read your saved list" (which it reports
loudly, and refuses to write over) and "you have no nodes". What it could not tell apart were the
two very different reasons a list can simply not be there:

• nobody has set this computer up yet — completely normal; and
• there were nodes here, and the file holding them is gone.

Both drew the same first-run screen. So a real loss could sit there unremarked, and the one moment
when something might still be recoverable would pass without anyone being told to look.

This was found on a real machine: a list holding two paired nodes on one day, and on another day no
list and no backup — with the app happily offering to set up a first node.

The fix

Vault Manager now leaves a small marker outside the list file, recording only how many nodes
this computer has ever had saved, and when that was last true. Evidence kept inside the thing that
went missing is not evidence, which is why it lives somewhere else.

If the list is then gone but the marker says nodes were once there, you get a plain statement of what
is known: how many there were, when they were last confirmed, whether the backup copy is gone too —
and, said outright, that Vault Manager did not delete it and cannot tell you what did. It also
points at the way back: pairing this computer with your node again using an owner code.

The marker holds no node address, no fingerprint and no credential — only a count and a date.
Anything more would be a second copy of the very file we are trying to protect.

It stays quiet unless it is sure

A warning that cries wolf is worse than none, so this one says nothing at all unless it can prove the
claim. A list that loads — even an empty one, because removing your last node is a normal thing to do
— is not a loss. A list that cannot be read keeps its own existing, louder message and its backup,
rather than being reported twice in two different ways. And if there is no marker, Vault Manager
simply does not know, which is not the same as knowing nothing was there, so it stays silent.

⚠ It cannot see backwards. The marker starts recording the first time your list is saved after
you install this version, so it has nothing to say about a list that went missing before then —
including the one that prompted this release.

You will see it without going looking for it

The warning itself lives on the Set up & manage a node tab, which is not the tab Vault Manager
opens on — and the whole point of the message is that you have no particular reason to go there,
since every other screen agrees you have no nodes. So while the warning stands, that tab is marked
on the very first screen, with a ⚠ in its label rather than a colour alone. The mark clears itself
once the warning no longer applies.

Also in this release

A sentence in the existing damaged-list warning used to read "there is no backup file … so nothing
has been saved on this computer yet" — the same mistake in miniature, guessing a first run from an
absence. It now gives both possible readings and admits that screen cannot tell which is true.

Verification

219 unit tests (three new), plus the call-site, page-structure and TLS guards, and two
walkthroughs driven against the built application: a first-run setup walk, and a full run through the
damaged state itself — because you cannot check a repair on a healthy machine, so the test creates
the damage first.

Every new guard was checked by deliberately breaking the thing it protects and confirming it
complains: shipping the warning switched on, letting the page guess instead of asking, letting an
ordinary save erase the marker, making it fire when it cannot actually tell, slipping a node's
address into the marker, leaving the first-screen mark stuck on for ever, and reducing that mark to a
colour. Eight for eight.

This release also adds a pre-publish check that reads the finished program's own dependency table and
refuses to publish it if it was built against a developer-only runtime — a fault that makes an
application fail to start on a computer without developer tools installed, while looking perfectly
fine on the machine it was built on. v0.7.2 and this release were both checked and are clean.

Downloads

Published under both VaultManager-* and VaultFlasher-* names; the bytes are identical.

NSIS setup.exe  sha256  fa5da2638d59d6c1b740a5f1a109a930ed015b883e3e5741fd1adf9d3d082edf
MSI             sha256  096928822ec86f4d3ce198292babf509f937089d1fe0bd2376b47d306c92667c

⚠ Compare hashes, not sizes.