Hacker News Reader

Comment by seanwilson | Hacker News Reader

Sounds like a better idea to just change the secret.

That is always the best course of action, no? Once it's out, assume it's compromised.

But then what do you do when you accidentally commit someone's private medical records or get a "right to be forgotten" order?

Edit: I had similar objections to "why not rework databases as an immutable diff history?" https://news.ycombinator.com/item?id=13581096

Why not both? :)

That's time you could be spending on adding a new feature or fixing a bug :) Just change the secret and be done with it!

And when someone new thinks "that password's wrong, it'll update it!"? Do both, gets rid of the issue on both sides and really doesn't take long :)

Why would they if the tip does not have any passwords in it? It's not like a potential contributor will search the commit log to see if there were once passwords around. Besides, making such changes in public changesets is rude, to say the least.

What I mean is, lots of folks seem to be saying to ignore the presence of the file and just change the password where it's used.

Removing the file, or the password and adding a comment, as well as changing the password where it's used is much less likely to end up with a re-added password later.

Of course, removing the file, adding it to .gitignore and changing the password makes it even harder as a contributor would have to work to add the password back, which is even less likely to happen.

Oh sorry I tought you were saying to remove it from VCS history (as said many times in the thread). I totally agree you.

Reply on news.ycombinator.com