Jul 18, 2020 Tags: devblog, kbs2, programming, rust
This post is at least a year old.
As of about a month ago,
kbs2 is officially in a “beta” state.
I’ll go over what exactly that means in this post.
As of 0.1.1, each kbs2 release also includes an auto-built Debian/Ubuntu package for x86_64.
Check out a recent release for a download link.
Additional packages will be coming soon.
The 0.1.x tree comes with a range of bugfixes and new features:
kbs2 now respects KBS2_CONFIG_DIR in the environment as a default value for the
-c, --config-dir option. It also propagates the current configuration directory to
every configured hook via that variable, ensuring that hooks always use the same configuration
directory as their invoker. See #62.kbs2 stores and keypairs on the same host.
See #63.commands.new.generate-on-empty (default: false) controls whether
the default secret generator is used to generate sensitive fields if the user leaves them empty.
This is similar to the --generate mode, but only performs the generation if you actually
leave the input empty (rather than unconditionally).
See #72.In addition, the following changes (among many others) were made prior to 0.1.0:
AgeCLI backend has been removed entirely, both age and rage, leaving only RageLib.
The CLI backend offered significantly worse performance and didn’t support wrapped keys, which are
more secure and have been the default for several alpha releases. Any keypairs generated by a CLI
backend should continue to be compatible with the RageLib backend.kbs2 now has unit tests. Help is appreciated with them, including CI tooling to report coverage
changes.kbs2 now uses the excellent anyhow library for error
handling, replacing the mess of From<>s that were used before.As of 0.1.x, users should expect greater stability from both the kbs2 CLI and the record
format (exposed via kbs2 dump --json).
The former’s stability is not enforced anywhere, but will not be changed (as a policy) except for security and bugfix related changes. These changes will be made according to a deprecation policy and will include warnings on use for several subsequent versions before total removal.
The record format was refactored several times during the alpha stage of development, and is now at a point where it reflects idiomatic use of serde. I don’t expect it to need to change again, except potentially to add additional record types. This should not affect consumers of the current types.
By way of example: here’s what you can always expect from a login record going forwards:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ kbs2 new test
Username: foo
Password: [hidden]
$ kbs2 dump -j test | json_pp
{
"body" : {
"fields" : {
"password" : "hunter2",
"username" : "foo"
},
"kind" : "Login"
},
"label" : "test",
"timestamp" : 1595097471
}
kbs2’s repository now has a contrib
directory. This directory contains resources that were previously split into other repositories,
such as useful external commands
and command hooks.
The files under contrib are not bundled as part of any release, and the directory should be
considered a central resource for non-official extensions to kbs2. Additions by others will
be happily accepted!
I do not have any lingering major features or bugs on the roadmap for a 1.0.0 release. In fact, the 1.0.0 milestone is already complete!
Despite this, kbs2 is going to remain a beta for at least a few more months. I have a few
reasons for this: