[zorbo]

Okay, so.

* misleading title. Goldman Sachs stole nothing.

* This guy steals code from Goldman Sachs.

* Covers his tracks. There is almost no reason why your password ever ends up in your bash history. If it does, you edit out only the password. Or you put a space before the command you run. At any rate, this guy should have known how to prevent his password from getting in the shell history and had no reason to delete his history.

* The guy talks to the cops

* Waves his rights to a lawyer

* Signs a confession

* Lets cops into his house without a search warrant.

* Doesn't testify at this trial.

This guy fully deserved what was coming to him. Goldman Sachs did nothing wrong here.

[emn13]

You're being totally unreasonable. Being naive (waiving rights, signing a "confession") doesn't mean you deserve to be abused. That's just barbaric.

As to clearing bash history, this isn't criminal, it's just a wise security measure. I've certainly cleared various log files when I knew they contained exploitable credentials. Why the heck would you waste time editing out specific statements? It's not like a bash history is valuable in any normal circumstance.

By the sound of it, he certainly didn't think he was doing anything wrong, otherwise he wouldn't have been helped the FBI so thoroughly.

Sounds to me like nothing he did would have been a problem if he'd have been upfront about it. Basically, Goldman encouraged an atmosphere where people went it alone, implicitly (but not formally) giving them permission to do what they want as long as it gets the job done. Now, after the job got done, they change the rules and screw their employee, who by all accounts did get the job done.

Frankly, if somebody needs to go to jail, it's his boss, by the sound of it.

[nmrm]

Bottom-line: "history -c" should never be interpreted as "covering your tracks". No one should be treating .history as a log file!

* First and most importantly, if you want a true log of history this can and should be achieved using a different mechanism (not effected by history -c).

* There exist bad CLI's which require entering the password on the command line. See the conversation below -- it took six posts on HN before the correct solution (make sure certain env vars are set to the right values) came out. So, hardly common knowledge.

- In fact, you space trick doesn't always work. Can I fire you for negligence if someone finds your .history since everyone should obviously know everything about bash history?

* If you run "man history", the very first thing you see is the -c option. Therefore, if you want to clear a password from your history file, this is mostly likely how you'll do it. You're effectively attributing criminal intent to anyone who's not sufficiently unix savvy.

* If you're treating .history is a log file, then you're being pretty damn close to criminally negligent with your logging practices (equivalent of providing an editor for apache's access.log on your homepage).

* Bash history files are not backed up, except perhaps accidentally with the rest of ~.

* History files rotate out after X commands. There is no way of guaranteeing that temporally-defined backup policies snapshot ~ before X commands are run.

Bash history is a "log file" in the same sense as the stack used for Word's "undo" mechanism is a "log file".

[GhotiFish]

>There is almost no reason why your password ever ends up in your bash history. If it does, you edit out only the password. Or you put a space before the command you run.

http://stackoverflow.com/questions/6475524/making-sure-comma...

TIL! Good tip!

[rwallace]

That's like saying if you walk down a dark alley you deserve to be mugged. It may well have been a mistake to walk down the alley, but that doesn't mean you deserved what was coming to you or that the mugger did nothing wrong.