Comment by theamk | Hacker News Reader

Comment by theamk | Hacker News Reader

The real problem is keeping sensetive information in .git directory. Like WTH would you put your password, in plaintext, in some general ini file? (or into a source file for that matter)?

When I see things like those, they look so wrong to me. But sadly it's apparently uncommon nowadays: not only random bloggers, even my coworkers see nothing wrong with putting passwords or tokens into general config or source code files. "it's just for a quick test"1 they say and then they forget about it and the password is getting checked in, or shown at screenshare meeting.

Maybe that's why there are so many security problems in industry? /rant

(For those curious: for git specifically, use ssh with key auth. If for some reason you don't want this, you can set up git's credential helper to use your OS key store; or use plaintext git-crendetials, or even just good-old .netrc. For source code, something like "PASSWORD = open("/home/user/.config/mypass.txt").read().strip()" is barely longer than hardcoding it, but 100% eliminates chance of accidental secret checkin or upload)

>The real problem is keeping sensetive information in .git directory. Like WTH would you put your password, in plaintext, in some general ini file? (or into a source file for that matter)?

People & organisations tend to follow the path of least resistance. If it's easier to put passwords into a plaintext config file than not, passwords will invariably end up in plaintext config files in some projects. `PASSWORD = open("/home/user/.config/mypass.txt").read().strip()` will work right up until a colleague without `"/home/user/.config/mypass.txt"` attempts to run the project - at which point it'll be replaced with `PASSWORD = "the_password123"`.

The only pragmatic solution is to make it easier to handle passwords securely than to handle them insecurely.

"Security at the expense of usability, comes at the expense of security." strikes once again (if you squint and see usability to include following the path of least resistance, which I think counts).

Good security is expensive. Bad security is cheap (be it the example you mentions or a multitude of other ways). Management will favor the bad security done cheaply because the cost of bad security is extremely rare, and when it does happen, it rarely falls on the managers head. Either no one gets blamed (general blame the company, if at all these days), or the developer who made the choice to go with the cheap option gets blamed.

> 100% eliminates chance of accidental secret checkin or upload

You've never worked with humans, have you?

At my work, I often see these 2 things throughout the codebase:

- an identifier for an environment variable that gives us the azure key vault scope (another identifier) - an identifier for the token to pull from that scope

Then the scope name and token name are used to pull the token secret value using the secrets api.

I am not experienced in how this is "supposed to be". Would it make sense to make both of these environment variables so neither identifier appears directly in code? (scope name and token name)

Thank you for the insight :)

The question you want is, "will anything bad happen if this source code is widely shared / leaks on the web" - and the answer in your case seem to be "no", the identifiers/token names are pretty useless without accompanying machine auth. You are fine.

> The real problem is keeping sensetive information in .git directory. Like WTH would you put your password, in plaintext, in some general ini file? (or into a source file for that matter)?

Sometimes it's not "you":

https://github.com/actions/checkout/issues/485

You know, Sun fixed this almost 30 years ago in the J2EE standard.

Gitleaks is the easiest way to deal with this. I make a point to include it in my build pipelines and have dev teams set it up as a precommit hook to prevent the problem.

Maybe they're use Google AppEngine and don't want to deal with storing config secrets the right way for it.

Reply on news.ycombinator.com