E_NO_SUCH_BLOG

Programming, philosophy, pedaling.


KBSecret 0.7.x: Secret Generators, Internal Fields, and Session Notifications

Jul 19, 2017

Tags: ruby, programming, devblog

Previously.

The KBSecret 0.7.x line has officially begun!

The release schedule was a little bit different this time, with three prereleases:

followed by normal releases:

Prereleases are a nice way for me to distribute not-quite-stable/not-fully-tested features without iterating too quickly or confusingly, so I’ll probably keep them around for the 0.8.x and future releases.

Secret Generators

Prior to 0.7.x, there was no way to generate the sensitive fields within a KBSecret record. Instead, KBSecret assumed that you already had knowledge of your secret(s), or were using an external tool to generate them.

Secret generators can be managed with the new kbsecret generator command:

# create a generator for 64-byte hexadecimal strings
$ kbsecret generator new extra-secure --format hex --length 64

# create a not very secure 2-byte base64 generator
$ kbsecret generator new not-secure --format base64 --length 2

# ...and then delete it, since we want to be secure!
$ kbsecret generator rm not-secure

In the future, the creation of weak generators may produce a warning.

The list of available generators can be obtained via kbsecret generators:

$ kbsecret generators
default
extra-secure

Note the default generator - like the default session, this generator gets used by default when the user requests secret generation but doesn’t specify a generator to use. It’s 16 bytes and hexadecimal by default, but this can be changed:

# use --force to override the existing values
kbsecret generator new default --force --format base64 --length 32

The application of generators is controlled by the -G, --generate and -g, --generator flags passed to kbsecret new:

# use the default generator, since specify -G but not -g
$ kbsecret new login bob-gmail -G
Username? bob@gmail.com

# use the generator specified by -g
$ kbsecret new environment alice-api -G -g extra-secure
Variable? ALICE_API_KEY

$ kbsecret dump-fields bob-gmail
username: bob@gmail.com
password: 172029465fe999686ee09a64b49dbaa5

Note how we don’t get asked for input on sensitive fields, and how the secret generator doesn’t care about record type - if a field is marked sensitive, it gets generated!

Note, also, that -G and -g are only respected during interactive input. If the user explicitly supplies -a, --args and fields as command-line arguments, then no generator is used.

More complex formats than just hex and base64 are planned.

Internal Fields

Just as 0.6.x brought the distinction between “sensitive” and “non-sensitive” fields, 0.7.x introduces “external” (the default) and “internal” field qualifiers.

If a field is marked as internal kbsecret new will not attempt to request it from the user.

The old (and incorrect) behavior:

# status, start, and stop are supposed to be populated internally, without the user!
$ kbsecret new todo cook-dinner
Todo? cook dinner at 8
Status? uh...
Start? what do i put here?
Stop? help!

and now:

# status, start, and stop are all ignored as internal fields
$ kbsecret new todo cook-dinner
Todo? cook dinner at 8

Just like with sensitive fields, the actual changes in definition are small.

The old KBSecret::Record::Todo field definitions:

data_field :todo, sensitive: false
data_field :status, sensitive: false
data_field :start, sensitive: false
data_field :stop, sensitive: false

And the new:

data_field :todo, sensitive: false
data_field :status, sensitive: false, internal: true
data_field :start, sensitive: false, internal: true
data_field :stop, sensitive: false, internal: true

Session Notifications

Until Keybase adds the concept of a “group” to Keybase/KBFS, KBSecret sessions are just directories shared between N users under a common directory:

/keybase/private/alice,bob,john/kbsecret/dev-team

This means that, while the actual secrets created in a shared session get propagated immediately, each user needs to configure the session for their own local installation:

$ kbsecret new-session -l dev-team -r dev-team -u alice,bob,john

…and now, KBSecret politely reminds you to do this when you’re added to a new session!

KBSecret Session Notification

This can be disabled by passing -n or --no-notify when creating a new session with kbsecret new-session.

…and some more, as usual

Besides the three features above, there was plenty of activity in the code. A sample of some of those changes:

Keep an eye out for 0.8.x!

- William