131–140 of 266 posts
One can do better by adding random lines/ logs in lot of files and sneakily remove password from one of them and then give a random commit name.
But then it all boils down to your mindset at that particular moment when you are commuting.
Just using a random commit name like 'minor bug fix', 'updated version' for these kind of commits will save a lot of headaches like this. One can do better by adding random lines/ logs in lot of files and sneakily remove password from one of them and then give a random commit name. But then it all boils down to your mindset at that particular moment when you are commuting.
Just change the leaked passwords, don't try to hide the commits.
I liked this one: https://github.com/squared-one/omniauth-unsplash/commit/072b... "... It's not really removing any password, is it? But hey, why not use the momentum ... wheeeeeeeeeeeeeeeeee!"
Just using a random commit name like 'minor bug fix', 'updated version' for these kind of commits will save a lot of headaches like this. One can do better by adding random lines/ logs in lot of files and sneakily remove password from one of them and then give a random commit name. But then it all boils down to your mindset at that particular moment when you are commuting.
You could upload an example file... but please don't put real passwords in the example file.
Just using a random commit name like 'minor bug fix', 'updated version' for these kind of commits will save a lot of headaches like this. One can do better by adding random lines/ logs in lot of files and sneakily remove password from one of them and then give a random commit name. But then it all boils down to your mindset at that particular moment when you are commuting.
If you leak a password to any public location, there is only one reasonable course of action: CHANGE IT!
Don't even bother rewriting the commit. Focus on changing that password right away, and while you're at it, figure out a better way to manage your secrets outside of your source code in the future. Mistakes happen, but they shouldn't be repeated.
Too many comments here recommend to clean up the commit and just hide the mistake under the rug. This is wrong. If you leak a password to any public location, there is only one reasonable course of action: CHANGE IT! Don't even bother rewriting the commit. Focus on changing that password right away, and while you're at it, figure out a better way to manage your secrets outside of your source code in the future. Mista…
Earlier quoted context omitted.
It is customer fault. However it should be pretty easy for them to set up a script to search github for this kind of stuff and automatically invalidate keys
At my work one of my coworkers accidentally put a secret token in a GitHub issue. Couple hours later he got an email from the sysadmin at the parent company saying his token finding script went off. He probably wouldn't have noticed for a long while if that script wasn't running.
If the token is XYZ and the script is searching https://github.com/search?utf8=%E2%9C%93&q=XYZ&type=Commits&...:
1. It's sharing the token with GitHub.
2. It's embedding the token as query-string parameter in a GET request, which is much more likely to be logged (than sending it as data in a POST request), and more likely to be available to less-privileged/less-trusted staff.
3. If the request is sent to a non-HTTPS endpoint, the query can be MITMd, revealing the token.
I'd be very wary of setting up a token-finding script, it feels like it adds more risk than it saves.
For anyone wondering, if you want to remove a file or secret you've already committed, you can use BFG Repo-Cleaner to go through your commit history and completely remove any trace of it. https://rtyley.github.io/bfg-repo-cleaner/
Sounds like a better idea to just change the secret.