Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I scanned all of GitHub's "oops commits" for leaked secrets

trufflesecurity.com

Post reply on HN
Print view View original

41–50 of 117 posts

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#41

Post by chickenzzzzu »

whyever wrote: post #40
oefrha wrote: post #30

> GitHub keeps these dangling commits, from what we can tell, forever. Not if you contact customer support and ask them to garbage collect your repo. What I do when I accidentally push something I don’t want public: - Force push; - Immediately rotate if it’s something like a secret key; - Contact customer support to gc the repo (and verify the commit is gone afterwards). (Of course you should consider the damage done…

If you rotated the secret, why do anything else? I don't think there is any potential further damage (except maybe reputational).

Anyone who puts weight on digging through a project to see if they've ever leaked a secret is guilty of encouraging an antipattern-- the guaranteed outcome is you'll have an organization petrified of shipping anything, in case someone interprets it as bad or a security risk, etc.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#42

Post by orthoxerox »

gghffguhvc wrote: post #17
volemo wrote: post #14

Earlier quoted context omitted.

If something got out to the internet, you won't get it back. There is little point in rewriting repo history if you have already made a secret public. Just change the secret as soon as you can.

The person who leaked it and the person/team that can rotate it might be in different silos or timezones etc. Rewriting the history is prudent but not sufficient.

That's why key revocation, like credit card blocking, should be a separate service that is available 24x7. Like, if you know the value of an AWS token, this should be sufficient data for you to call an AWS API that revokes it.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#43

Post by ramon156 »

edverma2 wrote: post #23

All devs should run open-source trufflehog as a precommit hook for all repositories on their local system. It’s not a foolproof solution, but it’s a small time investment to get set up and gives me reasonable assurance that I will not accidentally commit a secret. I’m unsure why this is not more widely considered standard practice.

If I'm honest, I don't know how much this happens at work, and even if it does it's not the end of the world. Just scratch the commit from existence.

In my head, the people who accidentally share secrets are also the people who couldn't setup trufflehog with a precommit.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#44

Post by bapak »

Cthulhu_ wrote: post #37
edverma2 wrote: post #23

All devs should run open-source trufflehog as a precommit hook for all repositories on their local system. It’s not a foolproof solution, but it’s a small time investment to get set up and gives me reasonable assurance that I will not accidentally commit a secret. I’m unsure why this is not more widely considered standard practice.

Pre-commit hooks are client-side only and opt-in; I've always been a big proponent of pre-commit hooks, as the sooner you find an issue the cheaper it is to fix, but over time pre-commit hooks that e.g. run unit tests tend to take longer and longer, and some people want to do rapid-fire commits instead of being a bit more thoughtful about it.

pre-commits require discipline:

- enforce them on CI too; not useful for secrets but at least you're eventually alerted

- do not run tasks that take more than a second; I do not want my commit commands to not be instant.

- do not prevent bad code from being committed, just enforce formatting; running tests on pre-commit is ridiculous, imagine Word stopping you from saving a file until you fixed all your misspellings.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#45

Post by orthoxerox »

eviks wrote: post #5
SillyUsername wrote: post #3

Git never forgets, this isn't really a shocking revelation.

What specific property of git mandates a website to not clean up those dangling commits?

Git has no de jure hierarchy of repositories. We de facto treat the GH repo as the primary one (and call it "origin"), but mechanically it's a peer repo. Even though it lets other repos push it around a bit and obeys commands like "change the branch to point to another commit", there are no commands to force it to delete the data.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#46

Post by ali_piccioni »

Cthulhu_ wrote: post #37
edverma2 wrote: post #23

All devs should run open-source trufflehog as a precommit hook for all repositories on their local system. It’s not a foolproof solution, but it’s a small time investment to get set up and gives me reasonable assurance that I will not accidentally commit a secret. I’m unsure why this is not more widely considered standard practice.

Pre-commit hooks are client-side only and opt-in; I've always been a big proponent of pre-commit hooks, as the sooner you find an issue the cheaper it is to fix, but over time pre-commit hooks that e.g. run unit tests tend to take longer and longer, and some people want to do rapid-fire commits instead of being a bit more thoughtful about it.

I moved all my precommit hooks to prepush hooks. I don’t need a spellchecker disrupting my headspace when I’m deep into a problem.

My developer environments are setup to reproduce CI test locally, but if I need to resort to “CI driven development” I can bypass prepush hooks with —-no-verify.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#47

Post by bapak »

cess11 wrote: post #29
UnreachableCode wrote: post #27

What I've never understood is, how is this an issue with private repos? Aside from open source projects I can't see the problem with accidentally doing this, even though it is a smell.

It's called private but actually shared with a very large corporation you don't control, likely running on infrastructure they don't control. Due to the CLOUD Act it's also shared with the US government.

Secrets gotta live somewhere. Are you supplying them every time you deploy or run CI?

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#48

Post by Arainach »

ramon156 wrote: post #43
edverma2 wrote: post #23

All devs should run open-source trufflehog as a precommit hook for all repositories on their local system. It’s not a foolproof solution, but it’s a small time investment to get set up and gives me reasonable assurance that I will not accidentally commit a secret. I’m unsure why this is not more widely considered standard practice.

If I'm honest, I don't know how much this happens at work, and even if it does it's not the end of the world. Just scratch the commit from existence. In my head, the people who accidentally share secrets are also the people who couldn't setup trufflehog with a precommit.

This isn't true in practice. Even among well educated high performing professionals, mistakes happen. Checklists save lives - in medicine, in aircraft maintenance, in all fields.

People who believe they know what they're doing get overconfident, move fast, and make mistakes. Seasoned woodworkers lose fingers. Experienced doctors lose patients to preventable mistakes. Senior developers wipe the prod database or make a commit they shouldn't.

https://hsph.harvard.edu/news/fall08checklist/

>In a study of 100 Michigan hospitals, he found that, 30 percent of the time, surgical teams skipped one of these five essential steps: washing hands; cleaning the site; draping the patient; donning surgical hat, gloves, and gown; and applying a sterile dressing. But after 15 months of using Pronovost’s simple checklist, the hospitals “cut their infection rate from 4 percent of cases to zero, saving 1,500 lives and nearly $200 million,”

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#50

Post by Cthulhu_ »

cess11 wrote: post #29
UnreachableCode wrote: post #27

What I've never understood is, how is this an issue with private repos? Aside from open source projects I can't see the problem with accidentally doing this, even though it is a smell.

It's called private but actually shared with a very large corporation you don't control, likely running on infrastructure they don't control. Due to the CLOUD Act it's also shared with the US government.

Exactly; you should fully expect the NSA to have a copy of these logs as well. It can be very valuable to have secret keys from companies in adversarial countries (including your own).

Example, there's an ICE reporting app now where people can anonymously report ICE sightings... but how anonymous is it really? Users report a location, that can be cross-referenced with location histories and quicky led back to an individual. There may be retaliation to users of this app if the spiral into authoritarianism in the US continues.

Post reply on HN