- 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.
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.I basically always do a
git add -p
Very 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.
What does that do?
Instead of just adding whole changed files, it starts an interactive mode where it shows every hunk of diffs one by one, and asks you to input yes or no for each change. Very helpful for doing your own mini code review or sanity check before you even commit.
I use vscode with plugins and manually add my files now. The workflow is beautiful.
If you ever Stage Selected Range in VSCode, that accomplishes basically the same thing as
git add -p
!That’s exactly why I do it
The
s
option is very useful to split the chunks.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
For personal projects that’s definitely a good idea. For team projects I like to keep that stuff in the project still so the “experience” of working in the project is mostly consistent.
I started using git-secret 2 years ago. It’s nice for making secrets part of the repo, while not being readable by anyone that isn’t explicitely allowed to do so (using GPG).
I think you really need the project specific gitignore as well, to make sure any other contributor that joins by default has the same protections in place.
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 -u
is pretty nice, it only adds modified files.I usually do
git add -p
which is interactive (helps avoid committing debugging prints and whatnot), but the other is nice for bigger refactors.