Live data from Hacker News

GitHub commit search: “remove password”

github.com

61–70 of 266 posts

Re: GitHub commit search: “remove password”

#61

Computers are supposed to be good at what imperfect humans are not. This only proves how primitive the tool is. That is, for example, if Gmail can ask "it looks like you forgot the attachment" why can't Git say "this is a public repo and you're about to commit and push passwords. Are you sure?" It's going to be easier to fix the tool than it is to make humans be perfect.

While there may well be common trends, Git is a tool for arbitrary content - it's going to be pretty hard to accurately find passwords/secrets being committed. There are tools out there for more specific sets of stuff, but expecting git to catch anything is a little much.

Re: GitHub commit search: “remove password”

#64
post #57

Computers are supposed to be good at what imperfect humans are not. This only proves how primitive the tool is. That is, for example, if Gmail can ask "it looks like you forgot the attachment" why can't Git say "this is a public repo and you're about to commit and push passwords. Are you sure?" It's going to be easier to fix the tool than it is to make humans be perfect.

How would git know that it's a password/key/whatever?

just make it search for files or variable assignments named "password" or "secret". That will catch the majority.

In comparison Gmail doesn't catch all cases either, if you say something like "here are" instead of I've attached it misses it.

Re: GitHub commit search: “remove password”

#66

Earlier quoted context omitted.

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.

Re: GitHub commit search: “remove password”

#67
post #57

Computers are supposed to be good at what imperfect humans are not. This only proves how primitive the tool is. That is, for example, if Gmail can ask "it looks like you forgot the attachment" why can't Git say "this is a public repo and you're about to commit and push passwords. Are you sure?" It's going to be easier to fix the tool than it is to make humans be perfect.

How would git know that it's a password/key/whatever?

Key is easy. The high entropy should tip you off.

Passwords, look for variables with the name password, passwd assigned strings.

Like Gmails attachment, it'll get stuff wrong, just make it easy to continue on.

Re: GitHub commit search: “remove password”

#69

Earlier quoted context omitted.

They do this for all of their own API keys already. They not only notify you but instantly invalidate a key pushed to a public repo. Annoyingly there is no way to turn it off even when you explicitly want to share an API key knowingly. But i'm more than fine with needing to "obfuscate" an API key or manage secrets correctly knowing it saves TONS of people.

Why would you ever want to share a valid Github API key publicly?

Continuous development, e.g. Jenkins? (Please don’t do this)

Re: GitHub commit search: “remove password”

#70

Computers are supposed to be good at what imperfect humans are not. This only proves how primitive the tool is. That is, for example, if Gmail can ask "it looks like you forgot the attachment" why can't Git say "this is a public repo and you're about to commit and push passwords. Are you sure?" It's going to be easier to fix the tool than it is to make humans be perfect.

Gmail can make a simple keyword search for a handfull of phrases in something that's known to be text

Git would have to first decide whether a file is a textfile or binary file, a decision that can be done reasonably well heuristically but that is undecidable in the general case. Then it has to parse text files for a long, curated list of known keywords that are only used for storing API keys and are not (usually) used in normal code. I'm not sure if that's even feasable.

And then of course git has no concept of "public" and "private" repos, so the entire task can't be handled well by git.

Post reply on HN