Google Search: Inurl:server Filetype:key “-----BEGIN RSA PRIVATE KEY-----”

Post by kevhito » Mon, Jul 31, 2017, 2:50 PM UTC

nthcolumn wrote: post #35

demarq wrote: post #2

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 publ…

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.

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

Post by gh02t » Mon, Jul 31, 2017, 2:55 PM UTC

kevhito wrote: post #41

nthcolumn wrote: post #35

Earlier quoted context omitted.

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.

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.

Post by kemitche » Mon, Jul 31, 2017, 3:20 PM UTC

rangibaby wrote: post #3

demarq wrote: post #2

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 publ…

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

Post by rwmj » Mon, Jul 31, 2017, 3:45 PM UTC

kemitche wrote: post #45

rangibaby wrote: post #3

Earlier quoted context omitted.

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

Test keys, example keys for documentation, etc. I'd be all for an optional, branch protection-like feature though.

Post by FilterSweep » Mon, Jul 31, 2017, 3:55 PM UTC

athenot wrote: post #23

It's worth pointing out that some of these are configuation examples, illustrations of how to set something up. (Though of course that carries the risk that less thorough users just copy-paste that into production and call it a day.)