ENOSUCHBLOG

Programming, philosophy, pedaling.

Jan 17, 2018

Tags: ruby, programming, devblog, kbsecret

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.

But what is it?

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:

# 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.

1.0 changes

Performance improvements

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:

The keybase -or-equivalent process was running

-or-equivalent process was running The kbfsfuse -or-equivalent process was running

-or-equivalent process was running The .kbfs_status file was present, meaning that the actual mountpoint was connected

This 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%.

Configuration stored in KBFS

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 -c

1.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.

Development statistics

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.

What’s next?

1.1 is next!

In terms of explicit goals, there are three:

Modularizing the individual CLI commands (#58)

Continuing to unit-test the CLI (#7)

Continuing to expand and improve shell completion (#4)

Help would be greatly appreciated on any and all of these, as well as on any other open issues.