ENOSUCHBLOG

Programming, philosophy, pedaling.

KBSecret 0.9.x: Many, Many Things

Dec 11, 2017 Tags: devblog, kbsecret, programming, ruby

Preword

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.

CLI consistency

As of KBSecret 0.9.6, some historic deficiencies/inconsistencies in the kbsecret CLI have been addressed:

The new-session and rm-session subcommands are now session new and session rm.

This is consistent with the generator new and generator rm subcommands, as well as the top-level new and rm commands for record management.

The env subcommand supports inline environment loading via --no-export.

One common way to load a program’s environment is via inline declarations, like so:

  $ FOO=bar BAZ=quux my-special-program

KBSecret can now do this via the --no-export flag:

  $ $(kbsecret env --no-export foo baz) my-special-program

The new 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 directories) away:

  # copies record1, record2, and record3 from foo-session to bar-session
  $ kbsecret cp foo-session bar-session record1 record2 record3

The -m,--move flag actually moves the record(s), deleting the originals.

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

This will come in handy if you’re trying to diagnose a crash or error in KBSecret.

Custom record types

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 magic-type record:

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 record type:

$ kbsecret types
todo
login
environment
unstructured
snippet
magic

You can find the KBSecret::Record API here, and some additional information about custom types here.

Keybase team support

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 -t, --team option, which takes the name of Keybase team to create the session under:

# creates the "beta-api-keys" session under the "megacorp" team
$ kbsecret session new -t megacorp beta-api-keys

Subteams are also supported:

# 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, the -c, --create-team flag can be applied:

# 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 -s, --session option with no extra work.

Other changes

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

Towards a 1.0 release

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!

Previously

Newer