5 ms·

This application does, for some reason, require write access to all of mine and my organisation's repos. Just no.

biggestlou 10y ago
We understand your reticence (Reflect employee here). Two things to note: 1. GitHub does not grant read-only access to repos. Any time you authorize a third-party app to access your repos, you are granting write access. We will never write to your repos, and our report card isn't doing anything out of the ordinary (i.e. it's not doing anything that TravisCI, Auth0, and a lot of other GitHub third-party apps don't do). 2. Your report card is accessible only by you and is not publicly viewable.
- Sir_Cmpwn 10y ago
  Github does provide read only access to your public repos. You could generate a report card for any github user with their username alone, no need to obtain account access (which I won't share, for that reason).
- jlgaddis 10y ago
  I've read your other replies here and you're apparently still missing the point several people are trying to make: The "report card" being public isn't the big concern. The problem is that they don't know you and they certainly don't trust you. Perhaps they trust some other devs/orgs ("TravisCI, Auth0, and a lot of other GitHub third-party apps") but that has nothing whatsoever to do with you (and "but you trust them, so why not us?" is a laughable argument). The "report card" requires write access to user's repositories -- and your statement that "we will never write to your repos" isn't worth the bits it was written on. While some folks are obviously okay with that, many aren't and likely never will be (regardless of how many times you repeat it) for any number of reasons (personal privacy, NDAs, etc.).
  - Pyxl101 10y ago
    Just to expand on the parent's point further: it's not just about what the service does, it's about what could happen in a worst-case scenario if the service is compromised by an attacker. Companies get hacked. Well-known companies get breached and their data stolen. When these companies store access credentials from users, those access credentials can be stolen too. For example, see the recent DataDog breach [1]. Security credentials that customers gave to DataDog, for the purpose of allowing DataDog to monitor their infrastructure, were compromied by an attacker: > the attacker gained unauthorized access to three of our AWS EC2 instances and a subset of our AWS S3 buckets. Those AWS resources included user credentials for the Datadog service, service metadata, and credentials shared with Datadog for third-party integrations. The attacker then used those credentials to penetrate systems owned by those customers! Customers were hacked not because the customer did anything wrong, but because they trusted DataDog, and DataDog did something wrong. Security-conscious customers will consider the implications of trusting any service they rely upon, and will consider "What could go wrong?". Very few companies get security right enough to avoid being breached. A company with read/write access to many users' GitHub repositories, including private repositories, will certainly be a major target for attackers. It's not so much that attackers care about source code per se. Rather, attackers know that all kinds of other information such as access credentials, username/passwords, etc. get checked into source control by accident or sometimes even intentionally. The credentials might be hidden in the sense that they don't show up in a branch currently, but are present in some historical version of some branch - perhaps a dotfile someone checked in by mistake, and deleted, but didn't erase the history of. It happens. An attacker will scan this source history and find those credentials. Every company that accepts credentials from customers to integrate with other parties should understand the pivotal role they play in the security of their customers. What the service intends to do is only part of the story. What the service could do if compromised by an attacker is an important piece of the story, and limiting this blast radius by embracing least privilege is an important part of earning the trust of security-conscious customers. It is a shame that GitHub does not make least privilege possible in this scenario, by failing to offer a form of access less powerful than read/write access. To solve this problem well, GitHub would ideally offer a read-only API, and perhaps a read-only metadata API that can view commit histories but not the content of commits. Then, a service integration built on this API can reassure its customers that, even if the service is hacked, an attacker has no ability to push commits to customer repos, nor view customer source code. [1] https://www.datadoghq.com/blog/2016-07-08-security-notice/ https://www.datadoghq.com/blog/2016-07-08-security-notice/

We understand your reticence (Reflect employee here). Two things to note: 1. GitHub does not grant read-only access to repos. Any time you authorize a third-party app to access your repos, you are granting write access. We will never write to your repos, and our report card isn't doing anything out of the ordinary (i.e. it's not doing anything that TravisCI, Auth0, and a lot of other GitHub third-party apps don't do). 2. Your report card is accessible only by you and is not publicly viewable.

Sir_Cmpwn 10y ago
Github does provide read only access to your public repos. You could generate a report card for any github user with their username alone, no need to obtain account access (which I won't share, for that reason).
jlgaddis 10y ago
I've read your other replies here and you're apparently still missing the point several people are trying to make: The "report card" being public isn't the big concern. The problem is that they don't know you and they certainly don't trust you. Perhaps they trust some other devs/orgs ("TravisCI, Auth0, and a lot of other GitHub third-party apps") but that has nothing whatsoever to do with you (and "but you trust them, so why not us?" is a laughable argument). The "report card" requires write access to user's repositories -- and your statement that "we will never write to your repos" isn't worth the bits it was written on. While some folks are obviously okay with that, many aren't and likely never will be (regardless of how many times you repeat it) for any number of reasons (personal privacy, NDAs, etc.).
- Pyxl101 10y ago
  Just to expand on the parent's point further: it's not just about what the service does, it's about what could happen in a worst-case scenario if the service is compromised by an attacker. Companies get hacked. Well-known companies get breached and their data stolen. When these companies store access credentials from users, those access credentials can be stolen too. For example, see the recent DataDog breach [1]. Security credentials that customers gave to DataDog, for the purpose of allowing DataDog to monitor their infrastructure, were compromied by an attacker: > the attacker gained unauthorized access to three of our AWS EC2 instances and a subset of our AWS S3 buckets. Those AWS resources included user credentials for the Datadog service, service metadata, and credentials shared with Datadog for third-party integrations. The attacker then used those credentials to penetrate systems owned by those customers! Customers were hacked not because the customer did anything wrong, but because they trusted DataDog, and DataDog did something wrong. Security-conscious customers will consider the implications of trusting any service they rely upon, and will consider "What could go wrong?". Very few companies get security right enough to avoid being breached. A company with read/write access to many users' GitHub repositories, including private repositories, will certainly be a major target for attackers. It's not so much that attackers care about source code per se. Rather, attackers know that all kinds of other information such as access credentials, username/passwords, etc. get checked into source control by accident or sometimes even intentionally. The credentials might be hidden in the sense that they don't show up in a branch currently, but are present in some historical version of some branch - perhaps a dotfile someone checked in by mistake, and deleted, but didn't erase the history of. It happens. An attacker will scan this source history and find those credentials. Every company that accepts credentials from customers to integrate with other parties should understand the pivotal role they play in the security of their customers. What the service intends to do is only part of the story. What the service could do if compromised by an attacker is an important piece of the story, and limiting this blast radius by embracing least privilege is an important part of earning the trust of security-conscious customers. It is a shame that GitHub does not make least privilege possible in this scenario, by failing to offer a form of access less powerful than read/write access. To solve this problem well, GitHub would ideally offer a read-only API, and perhaps a read-only metadata API that can view commit histories but not the content of commits. Then, a service integration built on this API can reassure its customers that, even if the service is hacked, an attacker has no ability to push commits to customer repos, nor view customer source code. [1] https://www.datadoghq.com/blog/2016-07-08-security-notice/ https://www.datadoghq.com/blog/2016-07-08-security-notice/