Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Genuine question here: isn’t it a standard security practice to avoid committing keys (or other secrets) to repos?

When you deal with high value amount of cryptocurrencies, you have a hardware wallet so things like these are not even possible in the first place, as the keys are safely stored in the hardware. Storing anything on disk (unencrypted at that) that corresponds to $40K is basically begging to be stolen from you.

Besides that, when you open source something that even has a chance of containing something you don't want to make public, you read through every single file before hitting publish.

> I’m thinking of scenarios where you might need to deploy your code + secrets on a remote server, say to authenticate with a third party API

Commonly you use environment variables for this. So the code references `process.env.MY_SECRET_VAR` or equivalent, and then you set that variable inside your server. That's the simplest way, then there are more complex/"secure" ways too, quick search for "secrets management" in your favorite search engine will tell you more.



Then you need to read through any file in any revision. Because if you have a newer commit with the secrets removed they are still in the history.


Or `rm -rf .git && git init && git commit -m "init"` and then read through. Common to scrap previous history when you go from private -> public repository anyways, a lot in order to scrub potential things like this to leak through.


If I'm at all worried about having accidentally committed secrets in the past, I usually create a new repo for the public release with a fresh git init.


Someone should come up with a paper-based version of hardware wallets that are easy to exchange.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: