Unfortunately, there is no such thing as read-only access to GitHub repos. Read/write access is the only scope that GitHub currently grants: https://developer.github.com/v3/oauth/#scopes. If you've given a third-party app access to your repos in the past (CircleCI, Auth0, TravisCI, Heroku, etc.), that access has been read/write.
You must not be familiar with OAuth authentication for Github. There is no way to access your repos to analyze except by allowing write-permissions. Github doesn't allow read-only unfortunately.
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.
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).
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.).
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.
But I still have to trust you with access to my private repos - read-write access, yet. I'm sure you're an entirely upstanding human being who would never abuse such access, but I don't know you from Adam's off ox, too.
If you've used Apiary, TravisCI, or a plethora of other third-party GitHub apps that access repos, then you have granted read/write access. We would love to see a read-only option but were bound by this limitation.
Read access to public repos just doesn't have to be granted - period. That's why there's no scope for it. The tool could just have excluded private repos.
And by you, githubreportcard, and by all of your devs, etc, etc. I'm no lawyer, but I have a feeling this is what some of those NDAs were talking about.
Sure, but GitHub and all their devs have access to your private repos too. If that doesn't violate the NDA I'm not sure why GHRC would violate it either unless they've been grated special exception.
The company put the code on GitHub, and the company has the rights to do so. The developer who signed the NDA doesn't have the rights to do that. And if the code was actually stored elsewhere and the developer decided to create their own private repo and upload the code there, that would be a violation of the NDA.
I'm a Technical Product Manager at GitHub. I just took a look at this (pretty cool, maybe we should have deeper user metrics...). I saw a couple of comments about the 'write access' so I just figured I'd chime in and point out that it's a required scope to get all of the private contrib info out of the API. I definitely encourage people to be mindful of what access they grant, but for what it's worth I did it :)
> it's a required scope to get all of the private contrib info out of the API
Is there a technical reason why that's so, or is it just an artifact of the way GitHub's OAuth scheme is set up? I can't think offhand of a reason why it should be the former, but my experience with GitHub private repos is somewhat seldom, so it's quite probable it is necessary for a reason of which I'm unaware.
6 months down the line: GitHub discovers a security breach, tracks it down to an advanced persistent threat that involved the attackers getting their conditionally malicious app front paged on HN which led to GH staff being baited into allowing said app write access on GH proprietary repos. Just kidding :p
While you're here and we're talking about granting private access to third party organizations... I've actually brought this up on several support request. I have several organizations authorized under my account which were active before the third party access was disabled by default.
The problem is I can't simply tell the company to disable third party access since it would revoke all the SSH keys across the board. Imagine the nightmare, support requests and coordination that would take to things back to normal. The other nuclear option is if I leave the organization before granting access to third party apps. It's been very frustrating for me as I'm hesitant to authorize third party apps since I can't pick and choose organization access on an individual level.
I replied to a couple other people, but to be clear, I didn't grant access to the GitHub Org. I only granted access to my own private repos (personal, non-work projects). I actually don't even have the ability to grant any permissions on the GitHub org :)
There's no preamble describing why this report is a thing, nor what will be included. I'm waiting on mine to be generated, but the landing page leaves much to be desired.
It would be awesome if I could see the whole image in the landing page without having to resize the page. Maybe you could allow the visitors to, you know, scroll a bit?
Also, I'm under some NDAs so I cannot allow access to the private repositories. It'd be great if it took only the public ones or public data.
GitHub data is public (for public repositories) and archived, so you don't even need to use auth.
Example superquick BigQuery for tabulating all 2016 Push Events to GitHub by a given user for each day-of-week (1 = Sunday):
SELECT DAYOFWEEK(created_at) as day_of_week, COUNT(*) as num_pushes
FROM TABLE_DATE_RANGE([githubarchive:day.], TIMESTAMP('2016-01-01'), TIMESTAMP('2016-12-31'))
WHERE type = "PushEvent" AND actor.login = "minimaxir"
GROUP BY day_of_week
ORDER BY day_of_week
Tabulating commits is possible too but requires JSON shenanigans. (Although the BigQuery data does not have commit dates which may not necessarily be the same as Push dates, so that may be a problem)
Open Source Report Card (OSRC) used to be a similar application that I used quite a bit with my friends. Unfortunately it seems to have broken with changes to the Github API.
If you're referring to it getting stuck at the "Top Collaborators by Changes" graph, I think that's actually the bottom.
I had the same experience in Safari, but after looking at the page source, I think that's actually the complete page. It also looks the same in Firefox Developer Edition.
Here's the report card image used[0] - it actually does end in the middle of that graph.
The only thing below that is a footer with the "Crafted by reflect" mark but it's hidden if the browser is wider than 768px (in which case it shows up on the top right).
Unfortunately, it only shows commits done via github directly - not commits that come in from other sources (I.E. if you have a gerrit instance, that mirrors to github)
I have over 200 open source repos, and 2-3 private once on GitHub. They are private for a reason and it's irresponsible of GitHub to "force" me to make this choice in order to participate in the echo-system of 3rd party apps that connect to GitHub. In todays developer world, you need a lot of these 3rd party tools in order to be a productive programmer (granted not this one, but hey).
It's even more irresponsible of this dev WHO WORKS AT GITHUB to take this fact to lightly. Read AND write access to both my public AND private repos is an insane amount of trust to put in another person. I'm sure this person is a stand up individual. But does he/she write secure code? How easy is it to gain access to his database of access tokens?
In this world of Yahoo/Sony/You-name-it hacks that we live in, I'm honestly surprised there haven't been a hack yet where someone got a hold on a whole bunch of access tokens to private repos. You could do A LOT of damage with this. I'll never sign up for a service such as this and the author should be ashamed to even suggest it.
Instead he/she should focus their time on fixing this issue at GitHub instead of making apps like this.
I think you're misattributing merge commits or pushes of repository histories where I'm not the author or something. You claim I've contributed over 2M lines of code in 2016, which... I don't think is right.
Looks like it's getting a bit overloaded at the moment, got the following error (and indeed, it's missing a good chunk of data):
We ran into a small snag
Some of your change information might be missing.
GitHub didn't generate repository statistics fast enough so we gave up after a few tries.
70 comments
[ 3.7 ms ] story [ 124 ms ] threadhttps://github.com/login/oauth/authorize?response_type=code&...
Just no.
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.
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.).
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/
If you've used Apiary, TravisCI, or a plethora of other third-party GitHub apps that access repos, then you have granted read/write access. We would love to see a read-only option but were bound by this limitation.
And by you, githubreportcard, and by all of your devs, etc, etc. I'm no lawyer, but I have a feeling this is what some of those NDAs were talking about.
https://github.com/login/oauth/authorize?response_type=code&...
Is there a technical reason why that's so, or is it just an artifact of the way GitHub's OAuth scheme is set up? I can't think offhand of a reason why it should be the former, but my experience with GitHub private repos is somewhat seldom, so it's quite probable it is necessary for a reason of which I'm unaware.
https://developer.github.com/early-access/integrations/
So you gave write access to what presumably are private company repos so that you could view a pretty report card about your commit activity?
That doesn't speak very well (to me) of the security practices espoused by your employer.
The problem is I can't simply tell the company to disable third party access since it would revoke all the SSH keys across the board. Imagine the nightmare, support requests and coordination that would take to things back to normal. The other nuclear option is if I leave the organization before granting access to third party apps. It's been very frustrating for me as I'm hesitant to authorize third party apps since I can't pick and choose organization access on an individual level.
- Total commits
- Unique repos
- Unique languages
- Total commits by day of week (my favorite graph as it shows a clear trend in my coding style)
- Average commits per day
- % of commits made on weekdays vs weekends
- Collaborators by changes (other GH users who collaborated on my repos)
- My additions (+ LOC)
- My deletions (- LOC)
- My open source changes
- Preferred language by repo count (owned)
- Stars on my stuff
- Forks of my stuff
- # of people subscribed to me
Some easy tweet templates at the top.
Also, I'm under some NDAs so I cannot allow access to the private repositories. It'd be great if it took only the public ones or public data.
Example superquick BigQuery for tabulating all 2016 Push Events to GitHub by a given user for each day-of-week (1 = Sunday):
Tabulating commits is possible too but requires JSON shenanigans. (Although the BigQuery data does not have commit dates which may not necessarily be the same as Push dates, so that may be a problem)That's a nice touch!
Tried using Internet Explorer 11 and nothing showed up at all...
In fact, I believe that that is essentially how Vault manages security.
OSRC: https://github.com/dfm/osrc
I had the same experience in Safari, but after looking at the page source, I think that's actually the complete page. It also looks the same in Firefox Developer Edition.
Here's the report card image used[0] - it actually does end in the middle of that graph.
The only thing below that is a footer with the "Crafted by reflect" mark but it's hidden if the browser is wider than 768px (in which case it shows up on the top right).
[0]: https://githubreportcard.reflect.io/images/screenshot.jpg
More constructively, people should publish the projects they worked on, not how often they press save.
It's even more irresponsible of this dev WHO WORKS AT GITHUB to take this fact to lightly. Read AND write access to both my public AND private repos is an insane amount of trust to put in another person. I'm sure this person is a stand up individual. But does he/she write secure code? How easy is it to gain access to his database of access tokens?
In this world of Yahoo/Sony/You-name-it hacks that we live in, I'm honestly surprised there haven't been a hack yet where someone got a hold on a whole bunch of access tokens to private repos. You could do A LOT of damage with this. I'll never sign up for a service such as this and the author should be ashamed to even suggest it.
Instead he/she should focus their time on fixing this issue at GitHub instead of making apps like this.
In case English is not your favorite language, the word I believe you're looking for is ecosystem.