Tags: ruby, programming, devblog, kbsecret
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.
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 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
flags passed to
# use the default generator, since specify -G but not -g $ kbsecret new login bob-gmail -G Username? email@example.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: firstname.lastname@example.org 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 are only respected during interactive input. If the user explicitly
--args and fields as command-line arguments, then no generator is used.
More complex formats than just
base64 are planned.
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!
# 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.
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
Until Keybase adds the concept of a "group" to Keybase/KBFS, KBSecret sessions are just directories shared between N users under a common directory:
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!
This can be disabled by passing
--no-notify when creating a new session with
Besides the three features above, there was plenty of activity in the code. A sample of some of those changes:
KBSecret::Exceptionsmodule as a measure against documentation clutter (f4737ca)
Keep an eye out for 0.8.x!