| ▲ | edverma2 a day ago |
| 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. |
|
| ▲ | ramon156 a day ago | parent | next [-] |
| 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. |
| |
| ▲ | Arainach a day ago | parent | next [-] | | 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,” | | |
| ▲ | xlii a day ago | parent | next [-] | | Aye. I made shameful mistake of submitting private key (development one so harmless) only because it wasn’t gitignored and prehook script crashed without deleting it). More of a political/audit problem than a real one. I guess I’m old enough to remember Murphy Laws and the one saying "safety system upon failure will bring protected system down first". | |
| ▲ | IshKebab a day ago | parent | prev [-] | | It's crazy how many people don't know this, despite it being fairly obvious. I guess it's hubris. I don't make stupid mistakes. You see it a lot in discussions around Rust. |
| |
| ▲ | oreilles a day ago | parent | prev [-] | | > Just scratch the commit from existence. Unfortunately, that is impossible: https://trufflesecurity.com/blog/anyone-can-access-deleted-a... |
|
|
| ▲ | Cthulhu_ a day ago | parent | prev [-] |
| 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. |
| |
| ▲ | bapak a day ago | parent | next [-] | | 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. | |
| ▲ | ali_piccioni a day ago | parent | prev | next [-] | | 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. | | |
| ▲ | pxc a day ago | parent [-] | | CI driven development results in so many shitty commits, though, and it's so slow. I find it very miserable. Pre-commit hooks should be much, much faster than most CI jobs; they should collectively run in less than a second if possible. |
| |
| ▲ | emmelaich a day ago | parent | prev | next [-] | | One good (and obviously bad) thing about Subversion was the ability to change history. As admin I was asked numerous times to change a commit message. To point to the correct Jira issue, for instance. Also easier to enforce pre-commit, since it was done server side. | |
| ▲ | SAI_Peregrinus a day ago | parent | prev [-] | | A CI system can run the precommit hooks, and fail if any files are changed or the hooks don't exit successfully. |
|