Developer posts secret key on GitHub, loses $40K in 2 minutes
Developer posts secret key on GitHub, loses $40K in 2 minutes
cointelegraph.com
Developer posts secret key on GitHub, loses $40K in 2 minutes
- Web3 developer Brian Guan lost $40,000 after accidentally posting his wallet's secret keys publicly on GitHub, with the funds being drained in just two minutes.
- The crypto community's reactions were mixed, with some offering support and others mocking Guan's previous comments about developers using AI tools like ChatGPT for coding.
- This incident highlights ongoing debates about security practices and the role of AI in software development within the crypto community.
If you have your secret keys in your repository you've already fucked up, long before you accidentally make that repository public.
One of the first things you should do in a repo is add a .gitignore file and make sure there are rules to ignore things like
*secret*or*private*etc. Also, I pretty much never usegit add .because I don't like the laziness of it and EVERY TIME one of my coworkers checked in secrets they were using that command.Even though that's a good extra precaution, per person config data, such as keys, should be stored outside of the repo, eg. in the parent directory or better in the users home dir. There is zero reason to have it in the repo. Even if you use a VM/containers, you can add the config in an extra mount/share.
I basically always do a
git add -pVery useful command and it works with other git commands as well.
Everytime a colleague asks me for help with git that’s the one rule I suggest them to use.
Better yet you can configure gitignore globally for git. I do this mostly to avoid polluting repo ignore files with my editor specific junk but *.key and similar can help prevent accidents.
https://git-scm.com/docs/gitignore
I never understood why everyone uses it as a ignore list. In my own and work repositories I always exclude everything by default and re-add stuff explicitly. I have had enough random crap checked in in the past by coworkers. Granted, the whole source folder is fully included but that has never been a problem.
git add -uis pretty nice, it only adds modified files.I usually do
git add -pwhich is interactive (helps avoid committing debugging prints and whatnot), but the other is nice for bigger refactors.I use this as a pre-commit hook https://github.com/americanexpress/earlybird
And that’s why you always
leave a noterecheck your .gitignore file before committingDoes Microsoft's GitHub offer any pre-receive hook configuration to reject commits pushed that contain private keys? Surely that would be a better feature to opt all users into rather than Windows Copilot.
You can also do
git diff --cachedto see all changes you added to the index.Ehhh. I mean, I have local repositories that contain things that I wouldn't want to share with the world. Using git to manage files isn't equivalent to wanting to publish publicly on github.
I could imagine ways that private information could leak. Like, okay, say you have some local project, and you're committing notes in a text file to the project. It's local, so you don't need to sanitize it, can put any related information into the notes. Or maybe you have a utility script that does some multi-machine build, has credentials embedded in it. But then over time, you clean the thing up for release and forget that the material is in the git history, and ten years later, do an open-source release or something.
I do kind of think that there's an argument that someone should make a "lint"-type script to automatically run on GitHub pushes to try and sanity-check and maybe warn about someone pushing out material that maybe they don't want to be pushing to the world. It'll never be a 100% solution, but it could maybe catch some portion of leakage.
Users often don't take care to separate private and public environments. They just dump all their stuff into one and expect their brain to make the correct decision all the time.
Put your private data into a private space. Never put private data into a mixed use space or a public space.
e.g. Don't use your personal email at work. Don't use your personal phone for business. Don't put your passwords or crypto keys in the same github or gitlab account or even instance and don't reuse passwords and keys, etc.
Having plain text secrets, or having secrets at all in a repository is always a bad practice. Even if it's a super-duper private/local/no one will ever see this repo.
That's exactly what pre-commit.com project is doing