Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> if this person is actually good at their job and takes it seriously, it's certain: he or she is not going to leak a secret again

If they were good at their job, they wouldn't have leaked the secret in the first place. The correct workflow is to:

1. Create commits that only change do one thing. Not possible to "forget" there were secrets added alongside another feature.

2. When adding secrets, make sure they're encrypted or added to the project's `.gitignore` equivalent.

I'm so sorry for a first-world engineer incompetent enough to commit a secret in a GitHub repository. They'll probably have to downsize from their mansion to a regular house. Meanwhile in the third world, many more competent people are starving or working some terrible menial job because they didn't have the right opportunities in life...



This sounds like naivety to me. I would bet most people here have committed a secret, even if it was later caught in a code review. If this wasn’t a common issue, all those tools that scan repos for secrets wouldn’t exist.

I once put secrets on a wiki page because I copied log snippets and a third party library naively dumped HTTP headers into the logs without filtering out their own API key. I shouldn’t have assumed the logs were secret free, but it’s also not an unreasonable assumption.


In a vacuum, sure. But in a workplace this workflow is best practice at best and even gets ignored. I've been able to accidently add a secret despite scans and I noticed it myself so it was quickly fixed. Still resulted in a discussion of how to prevent it in the future as nothing is perfect and you learn from mistakes.

Or you don't by simply firing the engineer and assume everyone in the entire workflow is perfect.


I'll do you one better. Start your .gitignore file with this line

  *


Mine all start with (and .dockerignore has a similar one)

    # Default block all
    /*
    # Specifically allow files and directories




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: