6 ms·

I think this problem is widespread enough and there are enough idiots out there(me included),that there should be a feature request for Github to provide a prom

by nutanc 12y ago

I think this problem is widespread enough and there are enough idiots out there(me included),that there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted.

mkal_tsr 12y ago
> there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted. Sure, just enumerate any and all possible types of sensitive data, the format they may be in, regex / matching functions to account for them (supported across 20+ programming languages) and I'm sure Github will have that done asap. Alternatively, don't commit passwords/API-keys/sensitive-info to your repo.
- lambda 12y ago
  > Alternatively, don't commit passwords/API-keys/sensitive-info to your repo. This is, of course, the right answer. However, it's frustrating that several frameworks make this very easy to get wrong. Anything that has an application.yml, database.yml, or similar configuration file that normally lives within the same directory as the source code, and which is intended to contain credentials, means that lots of people will make that mistake. It's one of the fundamental errors that you see so often in web frameworks like Rails, this whole idea of mixing application code and configuration files into one big tree. I don't know how this practice caught on, but it has, and it so frequently causes mistakes, both big ones like accidentally publishing credentials, and simply frustrating ones like confusing the difference between application code and configuration in ways that make it more difficult to have multiple local configurations and updating the application code independently.
  - deleted 12y ago
    [deleted]
- jemfinch 12y ago
  > Sure, just enumerate any and all possible types of sensitive data False dichotomy. It doesn't have to be "everything" or "nothing". An 80% solution here is better than nothing. I still find it useful that gmail warns me before I send an email without an attachment if I've written "I've attached" in an email. Can gmail detect with 100% accuracy if I intended to send an attachment? Of course not. But the 80% solution here still does me and lots of other people a lot of good.
  - mkal_tsr 12y ago
    80/20 rule goes a looooooong way, but relying on a 3rd party to handle your infosec is terribly misguided. Offloading your net/infoseq issues to a 3rd party doesn't guarantee you understand the attack surface nor mitigation steps. The advantage of doing it yourself is you learn and integrate knowledge as you go. Yes, more error prone, but imo it is more lasting as you (generally) retain the knowledge as time goes on. The issue with relying on a 3rd party is it becomes a "don't-care" because 'someone' else is taking care of it for you (github, sr. sw engr, sysadmin, etc.). There will never be a 100%-fool-proof "Did you mean to commit this sensitive unicode string?" but getting in front of that with a, "ok, I've checked my code, ran my tests, pruned the sensitive data, is there anything I'm missing?" will go a long way both in present and future times. There's an issue with your example. Google looks for the substr 'attach', but does it know that a file with a string 20 chars from the newline 50 lines deep with two single quotes is actually your root password? There's a world of difference between keying off of a word/phrase and understanding the context of a larger document+metadata. Trusting computers to do the latter will result in bad times for all, while learning for yourself can help spread the knowledge to those that are both technically inclined or not (infosec is everyone's issue!).
    - jemfinch 12y ago
      > but relying on a 3rd party to handle your infosec is terribly misguided. No one's suggesting anything like that. It's just a basic protection that Github could offer its users, because its users are humans, and humans make mistakes.
- nutanc 12y ago
  80:20 rule.I am sure, if we check for api_key,password(variants),key should help 80% of the people from making mistakes
  - palunon 12y ago
    Yeah, but you write api_key all over your code. The point were you define it is sensitive, but the place where you use it are not.
gojomo 12y ago
Similarly, a white hat could watch /events and warn users and/or services when credentials are 'burned'. (A major exploitable service like AWS might even want to do this itself.)
- krallin 12y ago
  AWS actually does that already — they'll ping you by email if they find one of your keys on GitHub!
  - TazeTSchnitzel 12y ago
    Why do they take longer than the black hats, though?
- jpdlla 12y ago
  Thinking of actually working on this. Seems like an interesting and useful little project. Can email users or create an issue on the repo.
zorked 12y ago
Amazon crawls Github looking for keys and disabled it. Happened to my company once!
RexRollman 12y ago
I don't know about that. It seems to me that you are wanting Github to do what the committer should be doing.
- deleted 12y ago
  [deleted]

by nutanc 12y ago

mkal_tsr 12y ago

> there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted. Sure, just enumerate any and all possible types of sensitive data, the format they may be in, regex / matching functions to account for them (supported across 20+ programming languages) and I'm sure Github will have that done asap. Alternatively, don't commit passwords/API-keys/sensitive-info to your repo.

lambda 12y ago
> Alternatively, don't commit passwords/API-keys/sensitive-info to your repo. This is, of course, the right answer. However, it's frustrating that several frameworks make this very easy to get wrong. Anything that has an application.yml, database.yml, or similar configuration file that normally lives within the same directory as the source code, and which is intended to contain credentials, means that lots of people will make that mistake. It's one of the fundamental errors that you see so often in web frameworks like Rails, this whole idea of mixing application code and configuration files into one big tree. I don't know how this practice caught on, but it has, and it so frequently causes mistakes, both big ones like accidentally publishing credentials, and simply frustrating ones like confusing the difference between application code and configuration in ways that make it more difficult to have multiple local configurations and updating the application code independently.
- deleted 12y ago
  [deleted]
jemfinch 12y ago
> Sure, just enumerate any and all possible types of sensitive data False dichotomy. It doesn't have to be "everything" or "nothing". An 80% solution here is better than nothing. I still find it useful that gmail warns me before I send an email without an attachment if I've written "I've attached" in an email. Can gmail detect with 100% accuracy if I intended to send an attachment? Of course not. But the 80% solution here still does me and lots of other people a lot of good.
- mkal_tsr 12y ago
  80/20 rule goes a looooooong way, but relying on a 3rd party to handle your infosec is terribly misguided. Offloading your net/infoseq issues to a 3rd party doesn't guarantee you understand the attack surface nor mitigation steps. The advantage of doing it yourself is you learn and integrate knowledge as you go. Yes, more error prone, but imo it is more lasting as you (generally) retain the knowledge as time goes on. The issue with relying on a 3rd party is it becomes a "don't-care" because 'someone' else is taking care of it for you (github, sr. sw engr, sysadmin, etc.). There will never be a 100%-fool-proof "Did you mean to commit this sensitive unicode string?" but getting in front of that with a, "ok, I've checked my code, ran my tests, pruned the sensitive data, is there anything I'm missing?" will go a long way both in present and future times. There's an issue with your example. Google looks for the substr 'attach', but does it know that a file with a string 20 chars from the newline 50 lines deep with two single quotes is actually your root password? There's a world of difference between keying off of a word/phrase and understanding the context of a larger document+metadata. Trusting computers to do the latter will result in bad times for all, while learning for yourself can help spread the knowledge to those that are both technically inclined or not (infosec is everyone's issue!).
  - jemfinch 12y ago
    > but relying on a 3rd party to handle your infosec is terribly misguided. No one's suggesting anything like that. It's just a basic protection that Github could offer its users, because its users are humans, and humans make mistakes.
nutanc 12y ago
80:20 rule.I am sure, if we check for api_key,password(variants),key should help 80% of the people from making mistakes
- palunon 12y ago
  Yeah, but you write api_key all over your code. The point were you define it is sensitive, but the place where you use it are not.

gojomo 12y ago

Similarly, a white hat could watch /events and warn users and/or services when credentials are 'burned'. (A major exploitable service like AWS might even want to do this itself.)

krallin 12y ago
AWS actually does that already — they'll ping you by email if they find one of your keys on GitHub!
- TazeTSchnitzel 12y ago
  Why do they take longer than the black hats, though?
jpdlla 12y ago
Thinking of actually working on this. Seems like an interesting and useful little project. Can email users or create an issue on the repo.

zorked 12y ago

Amazon crawls Github looking for keys and disabled it. Happened to my company once!

RexRollman 12y ago

I don't know about that. It seems to me that you are wanting Github to do what the committer should be doing.

deleted 12y ago
[deleted]