Dec 11, 2017 Tags: devblog, kbsecret, programming, ruby
I haven’t done a development blog post on KBSecret since the 0.7.x series.
As such, this post will cover changes through both the 0.8.x and 0.9.x releases. I’ll also (briefly) describe my plans for a 1.0 release.
Many of the changes detailed below were made by others, particularly during Hacktoberfest. You can find a list of contributors and their changes in this post.
As of KBSecret 0.9.6, some historic deficiencies/inconsistencies in the
kbsecret CLI have been
rm-session subcommands are now
session new and
This is consistent with the
generator new and
generator rm subcommands, as well as the
rm commands for record management.
env subcommand supports inline environment loading via
One common way to load a program’s environment is via inline declarations, like so:
1 $ FOO=bar BAZ=quux my-special-program
KBSecret can now do this via the
1 $ $(kbsecret env --no-export foo baz) my-special-program
cp subcommand for copying records between sessions.
Copying (or moving) records between sessions in KBSecret used to involve
manually shuffling the JSON files around.
kbsecret cp abstracts that (and session
1 2 # copies record1, record2, and record3 from foo-session to bar-session $ kbsecret cp foo-session bar-session record1 record2 record3
--move flag actually moves the record(s), deleting the originals.
1 2 # move record4 from foo-session to bar-session, deleting record4 from foo-session $ kbsecret cp -m foo-session bar-session record4
All built-in commands now support the
This will come in handy if you’re trying to diagnose a crash or error in KBSecret.
KBSecret users can now declare custom record types for use in their local installations. These
types are defined as Ruby classes, and are automatically loaded from the
~/.config/kbsecret/record/ directory at runtime.
Here’s an example of a
1 2 3 4 5 6 7 module KBSecret module Record class Magic < Abstract data_field :magic end end end
When placed in
~/.config/kbsecret/record, it’ll show up with (and behave like) every other
1 2 3 4 5 6 7 $ kbsecret types todo login environment unstructured snippet magic
You can find the
here, and some additional information about
custom types here.
Previously, KBSecret sessions could only be shared between a collection of users via a shared KBFS directory. This made the list of users in a session practically immutable, as adding or removing a user required the entire session to be copied (and re-encrypted).
That has changed now that Keybase has introduced Keybase teams, which have a flexible list of members with varying access rights (making it possible to share read-only records to some users).
A team-based session can be created via the
--team option, which takes the name of Keybase
team to create the session under:
1 2 # creates the "beta-api-keys" session under the "megacorp" team $ kbsecret session new -t megacorp beta-api-keys
Subteams are also supported:
1 2 # creates the "memos" session under the "megacorp.board" subteam $ kbsecret session new -t megacorp.board memos
The commands above require the Keybase team to already exist. If it doesn’t already exist,
--create-team flag can be applied:
1 2 # creates the "alpha-api-keys" session under the new "megacorp.devs" team $ kbsecret session new -ct megacorp.devs alpha-api-keys
Team-based sessions behave identically to individual and old-style shared sessions, meaning
that they can be passed to every other
keybase command via the
--session option with
no extra work.
Since this post spans two major releases (0.8.x and 0.9.x), I’ve omitted many (smaller) changes above.
However, some of them a brief mention:
kbsecret new -a is
It was dangerous and deprecated, and can be replaced by use of
kbsecret new -x.
The KBSecret repo now contains shell completions for ZSH and Fish.
KBSecret is now tested via CI. You can find the details for making Keybase run on a headless CI here.
The changes above are substantial, but are mostly interface-related: KBSecret’s Ruby API and record structure have not changed significantly in months.
As such, it looks like a 1.0 release is a short-team reality. The 1.0 release will mark the stability of both the API and CLI, with subsequent releases devoted to bugfixing, compatible feature additions, and unit testing.
My current plan is to prerelease 1.0 (
1.0.pre.1) on January 1st, 2018. One it rolls out smoothly
and nothing explodes in the first week, I’ll create the full release.
Thanks for reading!