7 ms·

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

by demarq 9y ago

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

rangibaby 9y ago
Is there a disadvantage to banning private keys in public repos?
- ATsch 9y ago
  Well, misdetection and examples for one.
- Artemis2 9y ago
  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 9y ago
  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
- tyingq 9y ago
  A fair amount of the google hits are for test certs that allow the test suite for the software to run.
- jcranmer 9y ago
  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.
- kemitche 9y ago
  Test keys, example keys for documentation, etc. I'd be all for an optional, branch protection-like feature though.
  - rwmj 9y ago
    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/Makefile.am#L323-L337 https://github.com/libguestfs/libguestfs/blob/master/p2v/Mak...
demarq 9y ago
Now I think about it there are companies better placed to do this, code climate, codacy et al.
deleted 9y ago
[deleted]
nthcolumn 9y ago
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 9y ago
  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 9y ago
    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 9y ago
    You forgot the * I put in.
Bromskloss 9y ago
"Hello! This is Github. Look what we found on your server! HAHAHA!"

by demarq 9y ago

rangibaby 9y ago

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

ATsch 9y ago
Well, misdetection and examples for one.
Artemis2 9y ago
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 9y ago
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
tyingq 9y ago
A fair amount of the google hits are for test certs that allow the test suite for the software to run.
jcranmer 9y ago
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.
kemitche 9y ago
Test keys, example keys for documentation, etc. I'd be all for an optional, branch protection-like feature though.
- rwmj 9y ago
  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/Makefile.am#L323-L337 https://github.com/libguestfs/libguestfs/blob/master/p2v/Mak...

demarq 9y ago

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

deleted 9y ago

[deleted]

nthcolumn 9y ago

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 9y ago
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 9y ago
  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 9y ago
  You forgot the * I put in.

Bromskloss 9y ago

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