[demarq]

Hmmm my idea would be

"Hello from github,

We detected that you uploaded credentials to NAME_OF_REPO. We strongly advise against this as it allows attackers to easily gain unauthorized access to your software and infrastructure.

Have a look at this blog where we discuss alternatives"

EDIT: Just to be clear, I'm not suggesting a ban at all, just a friendly email in response to commits that introduce credentials to public repos

[Bromskloss]

"Hello! This is Github. Look what we found on your server! HAHAHA!"

[rangibaby]

Is there a disadvantage to banning private keys in public repos?

[Artemis2]

I personally upload private keys in repos for some test scenarios and examples (dummy private keys of course). I often don’t want to write a test harness to generate the data for each run. Sue me!

[demarq]

Yes, business wise github is a git hosting site. If they started implementing rules on how you structure your application customers would get frustrated and move away.

Just to be clear, I'm not suggesting a ban at all, just a friendly email in response to commits that introduce credentials to public repos

[jcranmer]

People already mentioned the major use case of testing, but building a blacklist of keys (e.g., the Debian OpenSSL there-are-only-64K-keys fiasco) is a plausible option as well.

[tyingq]

A fair amount of the google hits are for test certs that allow the test suite for the software to run.

[kemitche]

Test keys, example keys for documentation, etc.

I'd be all for an optional, branch protection-like feature though.

[rwmj]

Is there a problem generating them? It's essentially just a single ‘ssh-keygen’ command, see eg:

https://github.com/libguestfs/libguestfs/blob/master/p2v/Mak...

[ATsch]

Well, misdetection and examples for one.

[demarq]

Now I think about it there are companies better placed to do this, code climate, codacy et al.

[nthcolumn]

I know you mean well but no charge should be introduced to mitigate against this stupidity. You are (probably correctly) assuming that the data in question is genuine. Nonetheless it is none of our business. rm -rf /* does not contain a warning message and that is the way it should be.

[kevhito]

Misleading? Because "rm -rf /" does give a warning. From info rm:

  `--preserve-root'
       Fail upon any attempt to remove the root directory, `/', when used
       with the `--recursive' option.  This is the default behavior.

[gh02t]

Yeah long ago it was not to be the case and rm would happily gobble /, but it started with Sun adding protection. It's been the default in GNU coreutils (hence the vast majority of Linux distros) since 2006.

[nthcolumn]

You forgot the * I put in.