Hacker News new | ask | show | jobs
by LeonidBugaev 3416 days ago
If you found a similar mistake in your repository, you can delete commit from history using: `git rebase --onto <commit-id>^ <commit-id>`. Or if you want actually rewrite it, see git rebase -i` documentation.
5 comments

A single person who checked out your repo before the force push will still have the credentials. Once this has been pushed to a public repo, assume that the credentials are burned and revoke them.
Indeed; but these actions complement each other.
if you revoke the credentials, removing them from the git history serves no purpose but disrupts everybody that has a clone of the repo. So you're doing harm for little benefit other than covering up the incident. A net loss, if you ask me.
It serves the purpose of removing a hint on your password patterns from public availability.

E: Oh, and just to preempt this, even saying "i use only random passwords with no pattern" is useful information, as is having a ballpark password length.

Don't have password patterns, problem solved. Knowing that my password is 20 random characters of all possible symbols will not reduce your search space by any significant amount.
Still useful, means there's no point in checking any < 20, which halves the search space. Or, on the outside, can be useful to abort any attempts at bruteforce by way of cost evaluation and move on to another target.
Too little, too late. Plenty of people watch the stream of recent commits to github, and can snatch an API key as soon as it's pushed. Removing the compromised, revoked key from your git history is like making sure your front door is closed properly after coming home to find you've been burgled.
I can think of a legitimate use case for that: cleaning up a that's about to be opened to the public (so no one who shouldn't have access to sensitive info has checked it out yet).
`git filter-branch` is a tool intended to remove sensitive material from git history. It requires a force push, of course.

If the keys/passwords are already pushed to GitHub or other public hostin, they should also be revoked.

Doesn't that requires a force push? Force pushes are acceptable for private repositories with a single user, but typically not in larger projects.

Just revoke the password/secret/whatever.

I find force pushes acceptable for topic branches of public repos. In fact, I use them a lot to leave behind clean history. Same as with squash merges, which technically also lose history.
It's better to push a similar name and let people decide if and when to rebase --onto the new upstream.

Squash merges are just bad. They destroy all the info that makes git handle branching and conflicts better than svn.

Or do both? Better safe than sorry.
It's better to just revoke and not re-write git history in a public repository. Re-writing history is pointless after the credentials are revoked, and causes a headache to others using your repository.
You'll have to revoke committed credentials regardless, as github is so frequently scrapped to find such content.
Just a tiny tweak - a handy shortcut to

<commit-id>^ <commit-id>

is

<commit-id>^!

I use it all the time with:

git diff <commit-id>^!