Hacker News new | ask | show | jobs
by rcaloras 3839 days ago
Creator here! Wow, didn't think this would get posted on HN all of a sudden. Would love to hear your feedback or ideas, I'm very actively developing the project. ryan@bashhub.com
1 comments

The security implications are terrifying.
I'd hope not. What winds up in your bash history?

[In case it wasn't clear, above was mildly tongue-in-cheek; secrets should not be in your bash history, but of course things approaching (and including) PII may well be]

Not saying I make of habit of this, but sometimes you have to pass sensitive things as arguments (passwords, api tokens, customer data, etc), it happens.

I think client side encryption by Bashhub would alleviate this security concern.

That doesn't have to mean typing it at your command line. My approach is typically to set shell variables with read (if I need to type it) or xclip (if I need to paste).

Of course, client side encryption would be great in any case.

One of the AWS config utilities comes to mind - you have to paste in your AWS key if running interactively.
Actually `aws configure` is interactive when it asks for input. Those values won't be stored in `history`.
If I accidentally hit enter too soon on a sudo command - parts of my password.

Also accidental pastes from other windows occasionally.

I expect I might take more care about maintaining a tidy history (see my other comment about splitting out separate histories by context), and reflexively clear bits of my history when I don't want them hanging around in the way of a ctrl-r - which would certainly include bits of passwords and anything pasted.

That said, this seems to use PROMPT_COMMAND to log off history, which would not give the opportunity for such tidying. Worrisome.

I can't see your comment about splitting history - this sounds like something I'd use, though.
https://news.ycombinator.com/item?id=10695029 is the comment, but it didn't contain much detail.

Splitting history is done fundamentally by setting HISTFILE - nothing too surprising about that.

But for my particular setup, I more broadly divide my shell use by context. I have a script called "session". `session $somename` looks for a screen (feel free to prefer tmux) session named $somename. If one exists, it attaches it. If not, it spawns it. Before doing so, it sets a shell variable SESSION to $somename. My bash_profile then customizes a lot of things based on the contents of that variable, including adding $SESSION to the prompt, and sourcing ~/.session/$SESSION/bash_profile. This lets me set context-specific aliases and such. Because SESSION is set above the terminal multiplexer, new windows spawned while in one context share the same context.

I've found most of this quite nice, but the history is the biggest win.

alias oops='history -d $((HISTCMD-2)) && history -d $((HISTCMD-1))'
Alas, not helpful here. The logging is done in PROMPT_COMMAND, meaning by the time you can type another command things are already logged and editing your history won't help. Hopefully (though I see no evidence of this, I've also only skimmed the material) things are marshalled somewhere locally and can be inspected/edited before being sent to the server.