• Ruby version (ruby -v): ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-darwin16]
• KBSecret version (kbsecret -v): kbsecret version 0.9.4.

Problem

Calling kbsecret login on a nonexistent record returns an empty string, rather than an error like similar methods do (e.g. kbsecret pass).

Replication

kbsecret login nonexistent-record

Expected behavior

returns Fatal: No such record.

Actual behavior

returns ""

• Ruby version (ruby -v): ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-darwin16]
• KBSecret version (kbsecret -v): kbsecret version 0.9.4.

Problem

I can create a new generator, but kbsecret new won't use it

Replication

$ bundle exec kbsecret generator new test -F hex -l 64
$ bundle exec kbsecret generators -a
default
	Format: hex
	Length: 16
test
	Format: hex
	Length: 64
$ bundle exec kbsecret new login --generator test test-login
Username? test
Password?
$ bundle exec kbsecret pass test-login
notsupposedtohappen

Also happens with abbreviated -g argument.
Does not happen with default generator (-G argument).

Expected behavior

Expected the password to be generated with the created generator

Actual behavior

I needed to provide the password manually

Please make sure to fill out everything below to help us with your issue!

• Ruby version (ruby -v): 2.5.0p0
• KBSecret version (kbsecret -v): 1.1.0

Problem

Installation via Brew results in the majority of commands throwing a "LoadError".

Replication

Installed via brew:

$ brew tap kbsecret/kbsecret
$ brew install kbsecret

Expected behavior

Command doesn't error out

Actual behavior

Command errors out... see screen shot.

Thank you!

Now that KBSecret's commands have been refactored to run in-process, KBSecret::Config's design mistakes are showing:

• KBSecret::Config was structured around the assumption that it would be re-loaded/re-initialized once per command, meaning that subsequent kbsecret commands would see each other's changes to the list of sessions and generators. That assumption holds when commands are run sequentially in the same process as well, but not when commands are run in their own forked processes (since each fork has its own copy of KBSecret::Config). fork is how we test kbsecret commands, so KBSecret::Config will need to be refactored.

Some ideas:

• Read/write the config with each Config method. This is slow, but straightforward.
• Introduce a reload! method that refreshes Config's state. This is faster, but a little confusing (in normal non-fork usage, developers will never need to call Config.reload!).

Right now, the kbsecret command calls internal commands (like list) via exec, just like external commands:

elsif external?(command) || internal?(command)
  exec expand(command), *args

This is slow, since it requires Ruby (and all dependent libraries) to be loaded twice: once in kbsecret itself, and once in the exec'd subcommand. It also makes it harder to generate code coverage on the CLI.

In order to avoid this reloading, all internal kbsecret commands should become first class objects under the KBSecret::CLI namespace. Some options:

• Subclass KBSecret::CLI in each, like KBsecret::CLI::New to kbsecret new.
• Create a new subhierarchy with a consistent mapping, like KBSecret::CLI::Command::New to kbsecret new.

KBSecret currently "supports" packaging for Debian (.deb), Arch, and Red Hat (.rpm) via fpm, but these generated packages are of dubious quality and are almost certainly broken in some form or other.

It would be nice to get first-class packages for these targets (and any others). If you have any experience with packaging, please let me know!

• Debian/Ubuntu
• Red Hat/Fedora
• Arch Linux (anatol/quarry#81)
• OS X (MacPorts/Homebrew)

Some notes/links:
For Debian/Ubuntu packaging:

• https://wiki.debian.org/Teams/Ruby/Packaging
• https://github.com/dcu/gem2deb

This is an issue tracking the progress of unit tests on KBSecret's command-line utilities. A check indicates (subjectively) reasonable coverage, one necessary condition of which is the presence of a test_$command.rb file.

• kbsecret version
• kbsecret types
• kbsecret sessions
• kbsecret new
• kbsecret login
• kbsecret list
• kbsecret help
• kbsecret env
• kbsecret conf
• kbsecret commands
• kbsecret raw-edit
• kbsecret stash-file
• kbsecret cp
• kbsecret todo
• kbsecret pass
• kbsecret dump-fields
• kbsecret rm
• kbsecret generators
• kbsecret generator
• kbsecret session

KBSecret already has unit tests for the library itself, but it would be nice to have tests for kbsecret and its subcommands as well.

Progress list:

• kbsecret commands (built-in)
• kbsecret conf (built-in)
• kbsecret cp
• kbsecret dump-fields
• kbsecret env
• kbsecret generator
• kbsecret generators
• kbsecret help (built-in)
• kbsecret list
• kbsecret login
• kbsecret new
• kbsecret new-session
• kbsecret pass
• kbsecret raw-edit
• kbsecret rm
• kbsecret rm-session
• kbsecret session
• kbsecret sessions
• kbsecret stash-file
• kbsecret todo
• kbsecret types (built-in)
• kbsecret version (built-in)

The current unit tests (make test) require a functional Keybase/KBFS installation, which is a problem for setting up CI testing on a service like Travis.

I'd like to set up CI and automatic coverage at some point (make coverage has the same problem as make test), so certain parts of KBSecret will probably need to be shimmed/mocked. An incomplete list of issues:

• KeybaseNotRunningError and KBFSNotRunningError need to be rescued, since they're raised immediately within lib/kbsecret.rb if Keybase and KBFS are not installed and running.
• KBSecret::Config needs to be mocked/refined to use a non-KBFS mountpoint. In principle, this should be as easy as refining DEFAULT_CONFIG. Another alternative is to just create the KBFS mountpoint (/keybase) on the CI as a normal directory, since KBSecret doesn't check to see if it's a real FUSE mountpoint.

kbsecret new-session notifies Keybase users when they get added to a new KBSecret session, but it would be nice to have a kbsecret discover-sessions command or similar to search for unconfigured KBSecret sessions.

This should be doable by searching each subdirectory in /keybase/private for a kbsecret directory and checking that directory's entries against the known sessions.

A potential usage example:

$ kbsecret discover-sessions
Found 2 unconfigured sessions...
Configure session1 (alice, bob, steve) [Y/n]? y
Label for session1 [session1]? some-label
Configure session2 (bob, caroline) [Y/n]? n

This might become unnecessary when Keybase finishes implementing KBFS groups.

It's currently possible to create custom record types by dropping them into lib/kbsecret/record/ as class definitions, but this isn't very friendly or practical. As such, it would be nice to provide a secondary loading location (like ~/.config/kbsecret/record/) where custom record types could be saved and referenced more conventionally.

It would also be nice to have a record type sharing system, whereby users could fetch new record types based on a unique identifier. Something like Homebrew's taps might work (e.g., woodruffw/extra-types/ssh would refer to github/woodruffw/kbsecret-extra-types/ssh).

Some ideas:

$ kbsecret type new foo # open up KBSecret::Record::Foo for editing in $EDITOR
$ kbsecret type fetch spec # fetch the specified record type
$ kbsecret type update # update all custom types

Some notes:

• Custom record types must never conflict with built-in types. In other words, if the user provides a custom login type, it should be ignored (and complained about loudly).
• Custom record types should be versioned or otherwise trackeable, so that people can remain up-to-date with types that they use in sessions shared with others.

Maintaining separate files for each shell completion syntax is a chore, and requires users to fetch the files from the repo (RubyGems doesn't provide a way to expose shell completion for a script).

So, it'd be nice if we could do this instead:

# .bashrc or .zshrc or whatever fish uses
# use $SHELL to dump the correct shell's completions
eval "$(kbsecret --completions)"

It might be nice to have a record type that stores an SSH identity file (private key) and some common configuration options, since synchronizing SSH keys and configurations across multiple hosts can be annoying.

Some usage ideas:

$ kbsecret new ssh foo user@host /path/to/key.priv -- [SSH options]

$ kbsecret ssh foo

The 1.0 release should not include -a, --args in kbsecret new, as it is fundamentally insecure.

A good programmatic replacement might be something like -x. --terse taking an IFS-separated list of fields on standard input.

KBSecret is currently English only, but international support would be good.

If anybody is interested in beginning the internationalization process for a language they speak, indicate it below.

This will come in handy: https://github.com/svenfuchs/i18n

KBSecret currently stores its config files in ~/.config/kbsecret.

This is consistent with XDG and fine for a single installation of KBSecret, but makes it a little annoying to sync sessions between multiple installations: you either have to add each session manually with kbsecret session new, or copy the config.yml over.

To avoid this, we could host KBSecret's configuration in KBFS directly, perhaps under /keybase/private/<user>/kbsecret/config. This, of course, would require the blacklisting of config as a session root.

Regardless of how this is accomplished, it changes the current configuration behavior substantially. As such, I'll probably introduce it gradually (make KBSecret::Config migrate itself).

Right now, KBSecret is tested on the CI by stubbing out tests for the presence of Keybase and KBFS and pretending that a temporary directory is the KBFS mountpoint.

This works, but it's really ugly and fragile. It also makes testing the CLI that much more difficult, since the CLI contains its own references and checks on Keybase.

Keybase should be able to run in a headless mode, so it would be great if we could get it running (with a test dummy account) on the CI.

Currently, in order to add or remove a user to a session, a user has to do something like this:

1. Deconfigure the session via kbsecret rm-session
2. Move the session directory over to the new KBFS userlist directory
3. Re-configure the session via kbsecret new-session

This should be automated to prevent user error.

Keybase is currently working on a "groups" feature that should make this (and KBSecret sessions in general) drastically simpler, so anybody interested in tackling this might want to hold off for a bit.

Please make sure to fill out everything below to help us with your issue!

• Ruby version (ruby -v): ruby 2.3.3p222 (2016-11-21) [x86_64-linux-gnu]
• KBSecret version (kbsecret -v): kbsecret version 0.9.4.

Problem

kbsecret interferes with keybase's usage of kbfs

Replication

keybase chat read (username)
Please any steps you took to replicate the problem.

Expected behavior

printing out the messages from the chat.
Please describe what you expected to happen.

Actual behavior

Please describe what actually happened.
▶ ERROR Unable to find conversation.
When considering as a username or a list of usernames, received error: EOF.
When considering as a team name, received error: Team does not exist.
Thank you!
Username: asternitix
Logged in: yes

Session: no session
is valid: yes
keys: unlocked

Key status:
stream: not cached
secret: stored
dev sig: cached
dev enc: cached
paper sig: not cached
paper enc: not cached
prompt: show
tsec: not cached

KBFS:
status: not running
version: 1.0.2-20171010160025+f71e33c2
log: /home/asternitx/.cache/keybase/keybase.kbfs.log

Service:
status: running
version: 1.0.34-20171010160025+8543c4734
log: /home/asternitx/.cache/keybase/keybase.service.log

Updater:
log: /home/asternitx/.cache/keybase/keybase.updater.log

Platform Information:
OS: linux
OS vers: Linux 3.8.11 x86_64-Debian GNU/Linux 9.2 (stretch)
Runtime: go1.9
Arch: amd64

Client:
version: 1.0.34-20171010160025+8543c4734

Desktop app:
status: not running
version:
log: /home/asternitx/.cache/keybase/Keybase.app.log

Config path: /home/asternitx/.config/keybase/config.json
Default user: asternitix
Other users:

command-line client:
keybase status [pid: 14189, version: 1.0.34-20171010160025+8543c4734]

kbsecret keeps kbfs from running

▶ ERROR GetConversationForCLILocal error: error unboxing chat message: Keybase services aren't running - KBFS client not found. On Linux you need to start them after an update with run_keybase command.

▶ ERROR GetConversationForCLILocal error: error unboxing chat message: Keybase services aren't running - KBFS client not found. On Linux you need to start them after an update with run_keybase command.

kbsecret pass should clear the clipboard after a sensible timeout period (15 seconds?).

This should be the default behavior when called with -c, --clipboard; users should be able to disable automatic clearing via -C, --no-clear or similar.

Examples:

$ kbsecret pass -c twitter
$ kbsecret pass -cC twitter

Now that kbsecret env has a -n, --no-export flag, it can be used like this:

$ $(kbsecret env -n api) important-command

which expands to something like this:

$ API_KEY=foobar important-command

However, kbsecret env also supports retrieving multiple environment records at once, and prints them out on individual lines:

$ kbsecret env -n api api2
API_KEY=foobar
API_KEY2=bazquux

This will break the use case above, as multiple environment settings should be separated by spaces before a command invocation:

$ # This is BROKEN!
$ $(kbsecret env -n api api2) important-command
$ # since it expands to this (note the newline between keys)
$ API_KEY=foobar
$ API_KEY2=bazquux important-command

Thus, it would be good to either create an -o, --one-line flag or make single-line output the default for -n, --no-export (with a -m, --multi-line toggle for multiple-line ouput).

I'm personally leaning towards the latter, since -o, --one-line doesn't make much sense for the other output modes (export-style and value-only).

KBSecret has been able to create sessions under Keybase teams for a while now, but it still needs the Keybase team to exist first before invoking kbsecret session new.

This is the currently flow:

$ keybase team create whatever-team
$ kbsecret session new -t whatever-team whatever-session

It'd be nice to use Keybase::Local::Team.create_team to do this for us, maybe with a -c, --create switch (which checks to see if the team given by -t, --team already exists, and then creates it if it doesn't).

$ kbsecret session new -ct whatever-team whatever-session

It would be nice for the kbsecret CLI to provide "did-you-mean" suggestions for misspelled record labels.

For example, the current behavior of kbsecret login:

$ kbsecret login foobarbar
Fatal: No such record(s).

With "did-you-mean":

$ kbsecret login foobarbar
Fatal: No such record(s).
Did you mean: foobarbaz?

Open to suggestions on how to implement this.

Many sites with 2FA provide a list of N recovery codes that can be used when SMS/the normal authentication method isn't available. It'd be nice to have a KBSecret support for accessing recovery codes in a structured fashion.

Recovery codes are almost always associated with a login, so it might not make sense to separate them from login-type records at all. Instead, they could be an optional component of a login record, allowing an interface like this:

# populate (or append to) the recovery code list for the `github` record
$ kbsecret recovery github < github-codes.txt

# retrieve (and remove) a recovery code from the `github` record
$ kbsecret recover github

Where github is a normal login-typed record.

KBSecret's generator interface is currently pretty inflexible -- all generators take a format and length, and the current Generator class just uses SecureRandom.

Ideally, generators would be more like record types -- extensible by users, and pluggable.

A mock hierarchy:

KBSecret::Generator::Abstract
  - KBSecret::Generator::Basic # the current `SecureRandom` implementation
  - KBSecret::Generator::Whatever

This would necessitate a configuration change, from:

:generators:
  :default:
    :format: hex
    :length: 16

to:

:generators:
  :default:
    :type: basic
    :options:
      :format: hex
      :length: 16

But this could be checked for, for backwards compatibility.

Currently, kbsecret rm only deletes one record at a time:

$ kbsecret rm foo        # this works
$ kbsecret rm foo bar    # this fails
Fatal: Too many arguments given (2, expected 1).

For consistency with kbsecret login and kbsecret env, kbsecret rm should be able to delete multiple records at once.

Passing a nonexistent record to kbsecret rm should fail the command before any records are deleted, just as it does now.

Currently, KBSecret provides (mediocre) bash completion support. It'd be nice to make this support more complete, and add support for some other shells.

An incomplete list (which will get edited/checked off as necessary):

• Bash (rewrite)
• Zsh
• Fish
• Ksh

See #56 for how future effort might be dedicated to this.

Right now, the CLI for sessions and generators is a bit inconsistent.

I wanted the kbsecret CLI to mimic that of git, where kbsecret new and kbsecret rm would be toplevel commands for records, and all other "add" and "remove" operators would be subcommands for secondary components (like managing sessions and generators). However, I didn't really plan for it.

As a result, this is what the CLI currently looks like:

$ kbsecret new record [...] # good!
$ kbsecret rm record [...] # good!

$ kbsecret generator new [...] # good!
$ kbsecret generator rm [...] # good!

$ kbsecret new-session session [...] # bad!
$ kbsecret rm-session session [...] # bad!

This is what the session CLI should look like:

$ kbsecret session new [...] # good!
$ kbsecret session rm [...] # good!

This would be more consistent with kbsecret generator, and would emphasize the priority of records, just as git emphasizes the working tree via git add and git rm.

Thanks to @arathnim for pointing this out.

We currently use Travis CI for tests and coverage. Switching to GitHub Actions would simplify things a bit.

• KBSecret 1.1.0
• Ruby 2.3.1

Problem

Homebrew's KBSecret errors attempting to create a new password. Additionally does not path its own internal Ruby.

Replication

brew tap kbsecret/kbsecret
brew install kbsecret
kbsecret session new --team standard_library
kbsecret new login gandi

Actual behavior

Ignoring ffi-1.9.23 because its extensions are not built.  Try: gem pristine ffi --version 1.9.23
Ignoring hitimes-1.2.6 because its extensions are not built.  Try: gem pristine hitimes --version 1.2.6
Ignoring inih-1.1.1 because its extensions are not built.  Try: gem pristine inih --version 1.1.1
/usr/local/Cellar/kbsecret/1.1.0/libexec/gems/inih-1.1.1/lib/inih.rb:3:in `require_relative': incompatible library version - /usr/local/Cellar/kbsecret/1.1.0/libexec/gems/inih-1.1.1/lib/ext/inih.bundle (fatal)
	from /usr/local/Cellar/kbsecret/1.1.0/libexec/gems/inih-1.1.1/lib/inih.rb:3:in `<top (required)>'
	from /Users/jackjennings/.rbenv/versions/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /Users/jackjennings/.rbenv/versions/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /usr/local/Cellar/kbsecret/1.1.0/libexec/gems/kbsecret-1.1.0/lib/kbsecret/config.rb:4:in `<top (required)>'
	from /usr/local/Cellar/kbsecret/1.1.0/libexec/gems/kbsecret-1.1.0/lib/kbsecret.rb:7:in `require_relative'
	from /usr/local/Cellar/kbsecret/1.1.0/libexec/gems/kbsecret-1.1.0/lib/kbsecret.rb:7:in `<top (required)>'
	from /Users/jackjennings/.rbenv/versions/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `require'
	from /Users/jackjennings/.rbenv/versions/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `rescue in require'
	from /Users/jackjennings/.rbenv/versions/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
	from /usr/local/Cellar/kbsecret/1.1.0/libexec/gems/kbsecret-1.1.0/lib/kbsecret/cli/kbsecret-session:4:in `<main>'

It would be nice to have some sorting functions built into kbsecret list. Some ideas:

• kbsecret list -d: sort by record date in descending order (oldest to newest)
• kbsecret list -D: sort by record date in ascending order (newest to oldest)
• kbsecret list -A: sort by record label (alphabetically)

Management of sessions and entries is fine. But how do I find an entry in a complex session structure? I know I can use "rgrep " but that is just a bad hack.

"kbsecret find " should search throuch all my accessible sessions.

Thanks for this useful application in the keybase world!

kbsecret new-session is currently invoked like this:

$ kbsecret new-session --team foo --label bar

Or like this, for non-team sessions:

$ kbsecret new-session --label foo --root foo --users alice,bob

This is inconsistent with many other kbsecret commands, which prefer an optionless argument for the record or session label. For example, kbsecret rm-session:

$ kbsecret rm-session foo

new-session should be more like rm-session, in order to minimize confusion and make usage more intuitive.

Currently, the only way to modify the behavior of a particular kbsecret command is to pass it options and arguments. For example, to force the creation of a record (possibly overwriting another record with the same label):

$ kbsecret new login --force gmail

This works nicely for individual invocations, but sometimes it's nice to set an option permanently (without resorting to shell-specific solutions like aliases and functions). Therefore, it would be good to allow users to configure default behavior on a per-command basis.

It would be best to keep this configuration isolated from config.yml, which gets rewritten by KBSecret occasionally and is generally less user-friendly. Instead, an INI file in the same directory would be good (perhaps commands.ini or commands.conf?).

Some ideas for formats:

• git style:

  [command]
  option = value ; corresponds to --option=value
  flag = true    ; corresponds to --flag
  flag = false   ; corresponds to --no-flag or nothing

  Pros: Obvious, easy to modify
  Cons: Harder to implement, annoying normalization of flags

• args style:

  [command]
  args = --option=value --flag

  Pros: Easy to implement, same syntax as command line, leaves the rest of the section open for other command configuration
  Cons: Harder to modify for users, potential word-splitting issues

Whatever gets used eventually, kbsecret commands will also need a way to ignore their configuration -- maybe something like --no-config.

Other ideas welcome!

Although env can spit out just secret values and fully-formed export shell lines, it'd be nice to also support output of the form

VARIABLE=value

Which lets users prepend commands that may need environment variables with keybase commands so that something like

$(kbsecret env aws) aws s3 ...

Alternatively (or in addition to) maybe there's a subcommand that could do something similar (set up an ephemeral environment variable(s) and execute the command line string). Thoughts?

A common user flow might be something like this:

1. Create a new record for testing in one's own session for testing (e.g., a new API key)
2. Once the record is finalized, add it to a group session so that others can access it

kbsecret currently does not provide an easy way to do this -- the user has to either manually cp the record file (annoying, and exposes KBSecret internal structure), or re-enter the record's fields in the new session (annoying and error prone).

It would be nice to have a kbsecret share-record or similar command that abstracts this task away.

Potential usage ideas:

# possible --delete or --delete-original to move the record entirely, instead of duplication
$ kbsecret share-record --from api-keys --to dev-team record1 record2 
$ kbsecret share-record api-keys dev-team record1 record2

Please make sure to fill out everything below to help us with your issue!

• Ruby version (ruby -v): ruby 2.4.2p198
• KBSecret version (kbsecret -v): kbsecret version 0.9.5.

Problem

ending test methods with ensure hides the error message that would describe the actual problem when a cli test fails

Replication

write a cli test wherein a record create step fails for whatever reason

Expected behavior

the test reports the error regarding the failed create step
e.g. "kbsecret new login failed because too few arguments"

Actual behavior

the test reports the error regarding the cleanup step in the ensure block
e.g. "kbsecret rm login failed because no such record"

Proposed solution

don't use ensure in the tests

Thank you!

Apologies for removing the issue template, this isn't a bug per se but a somewhat generic question that I'm not sure how to solve with a PR so I thought I'd confer with you first.

I use kbsecret quite a bit now to store several types of secrets, including some access keys that include characters like plus signs (+). The problem I'm running into is that when setting this values, environment records shellescape the string which ends up with values like the following:

$ kbsecret new env foobar --force -x <<< "VARIABLE:thing+with+plus"
$ kbsecret env foobar
export VARIABLE=thing\+with\+plus
$

I know the upstream ruby docs regarding shellescape indicate that things should work, but these types of environment values don't work (as far as I've seen) using tools like aws/cli53/etc.

I'm not sure what the right approach here is, as escaping the shell variable values makes sense, but out-of-the-box trying to store and then retrieve an environment variable with characters like these hand back values that don't work for all cases.

XDG specifies the Secret Storage specification, which applications can interface with via libsecret and D-Bus. Currently, the only implementations of this commonly available are GNOME-Keyring and KWallet.

It would be fantastic if KBSecret could provide a platform-agnostic implementation of the standard (and as a potential benefit, it may drive up the adoption of Keybase).