Jan 17, 2018 Tags: devblog, kbsecret, programming, ruby
This post is at least a year old.
After about a year of development, today is the day: KBSecret is getting a stable release.
This post will be a brief summary of the work since the 0.9.x tree. I’ll also list some development statistics and future milestones.
Here’s a brief explanation of KBSecret, if this is your first exposure to it:
KBSecret is a library and command-line utility for managing secrets. You can think of it as a souped up password manager, but with structured support for data other than passwords: it can store environment keys, code snippets, to-do notes, and entire files (among others).
Unlike pass and other password stores, KBSecret does not
require any GPG management or other keys/master passwords. Instead, it leverages
Keybase and KBFS to provide transparent
encryption — KBSecret records are just files stored on KBFS.
One of the advantages of leveraging Keybase is that it makes secret sharing incredibly easy:
multiple users can either share a directory containing mutual secrets, or belong to a Keybase team
with mutual secrets. For example, this is how a member of the bigcorp.devs Keybase team would
create a new shared session and add/access secrets within it:
1
2
3
4
5
6
7
8
9
10
11
12
# create a new session under the `bigcorp.devs` team called `foo-api`
$ kbsecret session new -t bigcorp.devs foo-api
# create a new `login` record under the `foo-api` session labeled `server-1`
$ kbsecret new login -s foo-api server-1
Username? foo-user
Password? *******
# now, retrieve the login information
$ kbsecret login -s foo-api server-1
Username: foo-user
Password: hunter2
Importantly, anybody with read access in bigcorp.devs can perform that last command, and
anybody with write access can update the login record as necessary. Each of the steps above
can also be performed via the Ruby library, making integration into existing applications easy.
The above is just a tiny taste of what KBSecret can do. For more information check out the website, which contains a starter’s guide and HTML manual pages.
One of the major performance bottlenecks in the 0.9.x tree was checking whether KBFS was “available,” meaning that all of the following requirements were satisfied:
keybase-or-equivalent process was runningkbfsfuse-or-equivalent process was running.kbfs_status file was present, meaning that the actual mountpoint was connectedThis third check (for .kbfs_status) was particularly expensive — under some network
conditions, it would take KBFS over a second to complete the stat!
To alleviate this, the 1.0 tree replaces the file-presence check with an actual mountpoint check, via the sys-filesystem gem. This alone (in local testing) improved the average command’s performance by about 30%.
Previous versions of KBSecret stored their configuration information in ~/.config/kbsecret/.
This is standard and easily discoverable, but caused problems across multiple machines: users
would have to sync their configurations manually, including any custom records.
To alleviate this, the 1.0 tree stores all configuration data in KBFS itself, under the
user’s private directory: /keybase/private/<user>/kbsecret/.config. This is a little less
discoverable, but eliminates the synchronization problem completely.
kbsecret conf -c1.0 also adds the -c, --commands flag to the kbsecret conf builtin. When passed,
kbsecret conf will open the commands configuration file instead of the main configuration
file.
See man 5 kbsecret-configuration for more information.
The first (public) commit to KBSecret was on February 2, 2017, and the first version (0.0.1) was
released on RubyGems the next day.
Since then, the main KBSecret repository has received 453 (soon to be 454) commits from 8 contributors, many of whom contributed for the first time during Hacktoberfest.
The main repository now consists of 1248 lines of Ruby code, 582 of which are library code. The remainder is CLI code.
The unit tests are 1614 lines of Ruby, which amounts to 96% coverage of the library’s codebase. The library is also 100% documented by YARD, including private methods, while the CLI is 100% documented by manual pages generated by ronn.
1.1 is next!
In terms of explicit goals, there are three:
Help would be greatly appreciated on any and all of these, as well as on any other open issues.