531
Developer posts secret key on GitHub, loses $40K in 2 minutes
(cointelegraph.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 07 Jun 2024
531 points (98.4% liked)
Technology
59674 readers
1892 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
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.
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.
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.
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