32 ms·

Unless I'm missing something, this looks like it ends up sprinkling all of your passwords into your .bash_history file. Maybe saving a credential should be a pr

by chias 9y ago

Unless I'm missing something, this looks like it ends up sprinkling all of your passwords into your .bash_history file. Maybe saving a credential should be a prompted action: $ kbsecret new login gmail "foo@example.com" Please enter the password: barbazquux

woodruffw 9y ago
You're not missing something; I documented that under "Security Considerations" for `kbsecret login` [1]. `kbsecret login` provides the `-i` and `--interactive` flags for exactly this purpose. They should probably be the default, but the reasoning for the current form was making scripting easy. $ kbsecret new login gmail -i Username? ***** Password? ********* (The asterisks don't actually show up, since tty echo is disabled for interactive input. This needs to be tweaked so that it's only disabled for sensitive inputs, but I haven't gotten around to that yet.) [1]: https://yossarian.net/docs/kbsecret-man/kbsecret-new.1.html https://yossarian.net/docs/kbsecret-man/kbsecret-new.1.html
- Daviey 9y ago
  You could use $stdout.isatty as an indicator if it is a shell or interactive and make the default for each?
  - woodruffw 9y ago
    That sounds like a good solution, thanks! Edit: I've created 0.4.1 for this change: `kbsecret login` now performs interactive input by default, provided that `$stdin.tty?` is true and the -a/--args flag is not passed. That provides both a more reasonable default and a way to override the safer behavior when testing for a TTY isn't a good enough indicator of noninteractivity.
- minitech 9y ago
  That’s unsafe even for scripts; unprivileged processes can, by default, read the argv of any other process. (Try `sudo -u nobody cat /proc/$(pgrep -n kbsecret)/cmdline`.)
  - woodruffw 9y ago
    Hmm. My first reaction is that this isn't a huge issue, since each `kbsecret` invocation runs for a fraction of a second. However, that's unreasonable of me. Do you know of any workaround for this? If it's unavoidable without requiring the user to change `/proc/`, then I'll probably have to get rid of argv input altogether.
    - minitech 9y ago
      There might be a workaround, but I think the common practice is to just avoid the problem with environment variables or by reading values from stdin.
aequitas 9y ago
Prefixing your shell command with a space will prevent it from ending up in history.
- kchr 9y ago
  Say whaaaaaaaaaat
  - kseistrup 9y ago
    $ echo $HISTCONTROL ignoreboth From ‘man bash’: HISTCONTROL A colon-separated list of values controlling how commands are saved on the history list. If the list of values includes ignorespace, lines which begin with a space character are not saved in the history list. A value of ignoredups causes lines matching the previous history entry to not be saved.
    - kchr 9y ago
      Bash - the gift that keeps giving :-) TIL!

by chias 9y ago

woodruffw 9y ago

You're not missing something; I documented that under "Security Considerations" for `kbsecret login` [1]. `kbsecret login` provides the `-i` and `--interactive` flags for exactly this purpose. They should probably be the default, but the reasoning for the current form was making scripting easy. $ kbsecret new login gmail -i Username? ***** Password? ********* (The asterisks don't actually show up, since tty echo is disabled for interactive input. This needs to be tweaked so that it's only disabled for sensitive inputs, but I haven't gotten around to that yet.) [1]: https://yossarian.net/docs/kbsecret-man/kbsecret-new.1.html https://yossarian.net/docs/kbsecret-man/kbsecret-new.1.html

Daviey 9y ago
You could use $stdout.isatty as an indicator if it is a shell or interactive and make the default for each?
- woodruffw 9y ago
  That sounds like a good solution, thanks! Edit: I've created 0.4.1 for this change: `kbsecret login` now performs interactive input by default, provided that `$stdin.tty?` is true and the -a/--args flag is not passed. That provides both a more reasonable default and a way to override the safer behavior when testing for a TTY isn't a good enough indicator of noninteractivity.
minitech 9y ago
That’s unsafe even for scripts; unprivileged processes can, by default, read the argv of any other process. (Try `sudo -u nobody cat /proc/$(pgrep -n kbsecret)/cmdline`.)
- woodruffw 9y ago
  Hmm. My first reaction is that this isn't a huge issue, since each `kbsecret` invocation runs for a fraction of a second. However, that's unreasonable of me. Do you know of any workaround for this? If it's unavoidable without requiring the user to change `/proc/`, then I'll probably have to get rid of argv input altogether.
  - minitech 9y ago
    There might be a workaround, but I think the common practice is to just avoid the problem with environment variables or by reading values from stdin.

aequitas 9y ago

Prefixing your shell command with a space will prevent it from ending up in history.

kchr 9y ago
Say whaaaaaaaaaat
- kseistrup 9y ago
  $ echo $HISTCONTROL ignoreboth From ‘man bash’: HISTCONTROL A colon-separated list of values controlling how commands are saved on the history list. If the list of values includes ignorespace, lines which begin with a space character are not saved in the history list. A value of ignoredups causes lines matching the previous history entry to not be saved.
  - kchr 9y ago
    Bash - the gift that keeps giving :-) TIL!