Jul 19, 2017 Tags: devblog, kbsecret, programming, ruby
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:
1
2
3
4
5
6
7
8
# 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:
1
2
3
$ 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:
1
2
# 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:
1
2
3
4
5
6
7
8
9
10
11
# 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.
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:
1
2
3
4
5
6
# 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:
1
2
3
# 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:
1
2
3
4
data_field :todo, sensitive: false
data_field :status, sensitive: false
data_field :start, sensitive: false
data_field :stop, sensitive: false
And the new:
1
2
3
4
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:
1
/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:
1
$ 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 -n or --no-notify when creating a new session with
kbsecret new-session.
Besides the three features above, there was plenty of activity in the code. A sample of some of those changes:
KBSecret::Exceptions module
as a measure against documentation clutter
(f4737ca)keybase versionKBSecret::CLI.create instead of KBSecret::CLI.newKeep an eye out for 0.8.x!
- William