this post was submitted on 07 Jun 2024
529 points (98.4% liked)

Technology

60047 readers
2777 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 2 years ago
MODERATORS
 
  • 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.
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 373 points 6 months ago (4 children)

The developer said he forgot that his secret keys were in the repository.

If you have your secret keys in your repository you've already fucked up, long before you accidentally make that repository public.

[–] [email protected] 92 points 6 months ago (5 children)

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 use git 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.

[–] lurch 55 points 6 months ago (1 children)

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.

[–] [email protected] 6 points 6 months ago (3 children)

What's the general consensus on storing encrypted data in the repo with the keys outside? I see people recommend that but I'm too paranoid and my secrets are very small in size so it hasn't been necessary.

[–] lurch 10 points 6 months ago* (last edited 6 months ago) (2 children)

the format of the encrypted file can give the attackers an advantage. if your code reads the decrypted file, the attacker can guess the first line is a comment or the name of a setting. a savvy person can combine that with the algorithm to perform a "known plaintext attack", for example by generating a number of possible passwords that would lead to files starting like that.

[–] [email protected] 5 points 6 months ago

That's smart. Anyone trying that should definitely have a machine-generated strong password!

[–] [email protected] 4 points 6 months ago

That's not quite the definition of known plaintext attack (cryptography nerd here), that's bruteforce with a "crib" to use older terminology (known patterns which allows you to test candidate keys).

A known plaintext attack is defined as an attack on the algorithm to extract the key faster than bruteforce with analytical attacks.

[–] [email protected] 8 points 6 months ago

I've seen that done for configuration management like Salt or Ansible. The repos for that were always hosted on internal Gitlab instances though.

[–] [email protected] 0 points 6 months ago

I see some of that in my job. We put encrypted data in settings files, and the keys for decryption are provided on the VMs where we deploy. The developers never actually see the keys.

I suppose it's as secure as the process for managing the production VMs, assuming the encryption isn't just md5!

[–] [email protected] 15 points 6 months ago (1 children)

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.

[–] kambusha 4 points 6 months ago (1 children)
[–] [email protected] 10 points 6 months ago (2 children)

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.

[–] [email protected] 4 points 6 months ago (1 children)

I use vscode with plugins and manually add my files now. The workflow is beautiful.

[–] [email protected] 2 points 6 months ago

If you ever Stage Selected Range in VSCode, that accomplishes basically the same thing as git add -p!

[–] [email protected] 3 points 6 months ago

That’s exactly why I do it

The s option is very useful to split the chunks.

[–] [email protected] 6 points 6 months ago (2 children)

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

[–] [email protected] 4 points 6 months ago (1 children)

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.

[–] [email protected] 2 points 6 months ago

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).

[–] [email protected] 2 points 6 months ago

Better yet you can configure gitignore globally for git.

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.

[–] [email protected] 5 points 6 months ago

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.

[–] sugar_in_your_tea 1 points 6 months ago

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.

[–] [email protected] 26 points 6 months ago (3 children)

And that’s why you always ~~leave a note~~ recheck your .gitignore file before committing

[–] [email protected] 7 points 6 months ago (3 children)

Does 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.

[–] [email protected] 4 points 6 months ago* (last edited 6 months ago) (1 children)

They notify but iirc only if you push a commit to a public repo. The dev in the article pushed it to a private repo, then later made the repo public.

[–] [email protected] 2 points 6 months ago

The docs say they can reject if you enable push protection, which is also available for private repos, just as a paid feature. It's free for public, but still needs to be enabled.

[–] [email protected] 2 points 6 months ago

they notify but that's all

[–] [email protected] 1 points 6 months ago

They have something called advanced security that can scan for things like secrets. It works on PRs though, so not very helpful if you have a public repo.

[–] [email protected] 1 points 6 months ago

You can also do git diff --cached to see all changes you added to the index.

[–] [email protected] 7 points 6 months ago (3 children)

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.

[–] [email protected] 16 points 6 months ago (1 children)

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.

[–] [email protected] 2 points 6 months ago* (last edited 6 months ago) (1 children)

Put your private data into a private space. Never put private data into a mixed use space or a public space.

Sure, but nothing I said conflicts with that.

I'm talking about a situation where someone has a private repository, and then one day down the line decide that they want to transition it to a public repository.

You're not creating the repository with the intention that it is public, nor intending to mix information that should be public and private together.

[–] [email protected] 5 points 6 months ago

If you don't have a policy of never committing private keys to any repo, you should choose a policy of never transitioning any private repo to public. IMO if you don't choose strict and effective policy with low cognitive burden, you will burn yourself sooner or later.

[–] [email protected] 14 points 6 months ago

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.

[–] [email protected] 3 points 6 months ago

That's exactly what pre-commit.com project is doing