91–100 of 117 posts
Maybe I missed it but the article doesn't mention the even easier way to see this: the activity tab. It has everything. Any force push to hide ugly prototype code is kept forever which annoys me. I wish we were able to remove stuff from there but the only way to do it is to email support it seems? Here it is for the test repo mentioned https://github.com/SharonBrizinov/test-oops-commit/activity
Where is that linked from? I've been using GitHub for years and never heard of this page.
Earlier quoted context omitted.
Secrets gotta live somewhere. Are you supplying them every time you deploy or run CI?
Yes. Either via a secret manager (eg vault) or configured as repo secrets if that kind of infra isn't available. https://docs.github.com/en/actions/how-tos/security-for-gith... Never commit secrets for any reason.
Same for your vault. The vault might be encrypted, but at some point you have to give the keys to the vault.
Your secrets are not safe from someone if someone needs them to run your code.
The other upside with environment variables is that they work across projects. Set & forget, assuming you memorized the name. Getting at tokens for OpenAI, AWS, GH, etc., is already a solved problem on my machine.
I understand why a lot of developers don't do this though. Especially on Windows, it takes a somewhat unpleasant # of clicks to get to the UI that manages these things. It's so much faster (relatively speaking) to paste the secret into your code. This kind of trivial laziness can really stack up on you if you aren't careful.
Earlier quoted context omitted.
It's a bad idea... - commit secret in currently private repo - 3 years later share / make public - forget the secret is in the commit history, and still valid, (and relatedly, having long-lived secrets is less secure) Sure that might not happen for you, but the chances increase dramatically if you make a habit of commiting secrets.
In a large messaging app I worked for we self hosted a gitlab instance for this exact reason. I thought it was over the top but now I get it, you can never be too sure.
Earlier quoted context omitted.
Yes. Either via a secret manager (eg vault) or configured as repo secrets if that kind of infra isn't available. https://docs.github.com/en/actions/how-tos/security-for-gith... Never commit secrets for any reason.
Repo secrets are just stored on someone's computer and they obviously have the keys. This is what I mean. Same for your vault. The vault might be encrypted, but at some point you have to give the keys to the vault. Your secrets are not safe from someone if someone needs them to run your code.
This is true. I don't disagree with that or you're assessment of repo secrets.
My comment was in the context of the grandparent committing secrets to a private repo which is a bad practice (regardless of visibility). You could do that for tests, sure (I would suggestion creating random secrets for each test when you can), but then you're creating a bad habit. If you can't use random secrets for tests repo secrets would be acceptable, but I wouldn't use them beyond that.
For CI and deploys I would opt for some kind of secret manager. CI can be run on your own infrastructure, secret managers can be run on your own infrastructure, etc...
But somewhere in the stack secret(s) will be exposed to _someone_.
Earlier quoted context omitted.
1. Not all secrets can be rotated. E.g. I can't just "rotate" my home address, which I prefer to be private. 2. Even for rotatable secrets, "I don't think there is any potential further damage" rests on the assumption that the secret is 100% invalidated everywhere. What if there are obscure and/or neglected systems, possibly outside of your control, that still accept that secret? No system is bug-free. If I can take…
> 1. Not all secrets can be rotated. E.g. I can't just "rotate" my home address, which I prefer to be private. Reporter can sell their current house and move to another home as a workaround Closing ticket as workaround provided.
Thanks for being a great team player!
I got tired of "oops" over time and started abusing environment variables. If you have enough discipline to spend 10 seconds configuring them, you'll never have to worry about magic strings accidentally getting sucked up into source control. The other upside with environment variables is that they work across projects. Set & forget, assuming you memorized the name. Getting at tokens for OpenAI, AWS, GH, etc., is alre…
Earlier quoted context omitted.
It's called private but actually shared with a very large corporation you don't control, likely running on infrastructure they don't control. Due to the CLOUD Act it's also shared with the US government.
Secrets gotta live somewhere. Are you supplying them every time you deploy or run CI?
Earlier quoted context omitted.
The problem here is that GitHub keeps the ref logs even for commits that no longer exist. I don’t see how BFG helps here
it rewrites the history. Isn't that really enough? You can remove all the keys from the git history. and I agree , i forget the point about rotating the key which i do always in first .
Also, if you’re going to rotate your secrets (which you absolutely should do regardless) then everything else is pointless because it’s now just an invalid credential.