May 3, 2021 Tags: devblog, kbs2, programming, rust
This post is at least a year old.
As of yesterday and beginning with 0.3.0,
kbs2 is officially in its third (and final) beta series.
This post is going to follow the same structure as the previous announcement posts:
And, as before, read this first
if you aren’t previously familiar with kbs2.
kbs2’s version-by-version changes are now tracked in a project
CHANGELOG. Going forwards,
this CHANGELOG will serve as the primary source of ground truth for releases (and release series),
rather than blog posts like this one. It’s also kept in sync with each release via some
lovely cargo release rules.
Hooray for (semi) automated in-tree change tracking!
kbs2 has learned a new subcommand: kbs2 rekey.
kbs2 rekey does exactly what I proposed kbs2 reroll would do in the 0.2.x series post:
it creates a brand new wrapped keypair, and re-encrypts the entire secret store using
the new key.
You can think of it as a more extreme version of kbs2 rewrap —
instead of changing only the master password, it blows away the entire key for a particular
config and re-encrypts everything with a brand new one. It even goes to the trouble
of flushing your old key(s) from kbs2 agent, meaning that this will “just work”
with no explicit kbs2 agent subcommands:
1
2
3
4
5
6
7
8
# list all records, encrypted with old key
$ kbs2 list
# follow all prompts
$ kbs2 rekey
# list all records, encrypted with new key
$ kbs2 list
The 0.3.x series brings a change to how external commands are expected to modify kbs2’s
configuration file.
Previously, external commands were allowed and expected to modify the [commands.<command>]
hierarchy, where <command> is the external command’s name.
This worked just fine for the external commands themselves, but wasn’t tracked by kbs2’s own
config loading. Consequently, any kbs2 subcommand that happened to rewrite the config file
(like kbs2 rekey does) would erase the user’s external command configurations.
The fix: as of 0.3.x, external commands are expected to use the [commands.ext.<command>]
hierarchy instead. kbs2 knows how to track this, and won’t clobber it on re-keying
(or any future destructive config operations). All external commands supplied via
kbs2’s contrib/ directory have already been updated.
By way of example: the old (0.2.x) style:
1
2
[commands.dmenu-pass]
notify-username = true
…and the new style:
1
2
[commands.ext.dmenu-pass]
notify-username = true
I intend for the 0.3.x series to be the final beta series for kbs2: after this will be 1.0.
The remaining items for a 1.0 release are tagged with a corresponding milestone on GitHub.
To highlight a few:
kbs2 agent’s internals need to be slightly refactored, to prefer public keys
as identifiers rather than the canonical filesystem path to each private key. This should
not result in any user-facing changes, but will eliminate a few of the tedious
steps needed by key-management subcommands like kbs2 rewrap and kbs2 rekey.
kbs2 needs to be packaged for more systems. Debian-based systems are
officially packaged for; there exist community-maintained
AUR
and
Nix.
Homebrew and RPM are musts; all others would be nice to have.