ENOSUCHBLOG

Programming, philosophy, pedaling.


kbs2 0.3.x

May 3, 2021

Tags: programming, devblog, rust, kbs2

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.


Changes

Project-level

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!

CLI

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

Configuration

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

Roadmap

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: