uBixVault 1.5 — The Whole Lifecycle in the Browser, and Tokens That Know Their Parents

The console can start a vault now

Until 1.5 the web console assumed someone had already done the hard part. A brand-new vault had to be initialized from the command line, and a sealed one unsealed from the command line — the moment you most want a clear screen in front of you, you got curl.

Now the console does both. On a new vault it asks how many key shares you want and how many it should take to unseal, then shows the shares and the root token once, each with a copy button, and keeps them on screen until you say you’ve stored them. That last part is a small thing that mattered: the obvious implementation hides the panel the instant the vault reports “initialized” — which is the instant it has just shown you the keys. On a sealed vault it takes shares one at a time and counts up, and it never keeps a share in the page.

Tested in a real browser, every commit

The console has been “beta” partly because nothing tested it the way a person uses it. 1.5 adds a test that drives the actual console in headless Chrome: initialize, unseal with a wrong share in the middle, sign in with a token, sign in with a username and password, sign out — and then asks the server whether sign-out really revoked the token, and whether “forget token” really left a pasted root token alone. It runs on every commit now. Its first run in CI passed; I made sure it can fail by breaking the keys-stay-on-screen logic and watching it catch that.

Tokens that know their parents

1.3 fixed the worst token bug — a token allowed to create tokens could mint a root one — and left one thing on the list: revoking a token didn’t touch the tokens it had created. They lived until they expired.

In 1.5 they don’t. A token created by an ordinary token is its child, and revoking the parent — or letting it expire — revokes the children, and theirs, cleaning up each one’s private storage on the way. Tokens an operator creates with root or sudo stay independent on purpose: revoking the token you used to issue a year’s worth of CI credentials shouldn’t take the CI credentials with it.

The other half: every auth method can now set a token_max_ttl, so a login role for a CI job can say “an hour, and no renewing past it” instead of inheriting the system’s 32 days.

Still true

A better console and tidier tokens are not an audit. uBixVault still has not had an independent security review, and that remains the most important thing on its list.

uBixVault 1.5.0 is BSD 3-Clause, on GitHub at github.com/cwolsen7905/ubixvault, tagged v1.5.0, with signed multi-arch images.