GitHub Report Card(githubreportcard.com)
githubreportcard.com
GitHub Report Card
http://githubreportcard.com/
70 comments
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 :)
> I definitely encourage people to be mindful of what access they grant, but for what it's worth I did it :)
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.
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.
Ah, good question! No, I did not request access to the GitHub private org.
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
Heh. Yeah, I responded to clarify that I did not grant access to that Org.
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.
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.
> 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.
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.
I wonder too, especially considering it's possible to have collaborators with read-only access to private repos.
The new Integrations api they announced at their conference should allow way more granular control. Still in beta though AFAIK.
https://developer.github.com/early-access/integrations/
https://developer.github.com/early-access/integrations/
You are totally correct.
Why should I be mindful when someone from Github (the company where I host lot of code) does not?
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 :)
If you want to grant it read-only to public repos, try this link:
https://github.com/login/oauth/authorize?response_type=code&...
https://github.com/login/oauth/authorize?response_type=code&...
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.
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.
This app was made by Reflect not Github. By the way, github has this coming down their development pipeline: https://developer.github.com/early-access/integrations/
More and more apps require this. It's ridiculous for even code scoring to require total access to a GitHub account.
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):
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
Once you have your report card, don't forget to revoke access. https://github.com/settings/applications
Good point. I can see a lot of people are worried this is getting write access. Thanks for providing a link and a reminder.
This immediately suggests the ability to provide permissions only for a specific transaction at a time.
In fact, I believe that that is essentially how Vault manages security.
In fact, I believe that that is essentially how Vault manages security.
Please include a checkbox to exclude private repos. I have a lot of private work that I just can't let anyone see. Thank you!
Important note: these reports are accessible only by you, the user. They are not publicly available.
> these reports are accessible only by you
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.
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.
Putting NDA'd code on github without permission would certainly violate it.
[deleted]
"Any third-party access" is often an NDA-violating action.
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.
Unfortunately, GitHub does not provide read-only access to repos, be they public or private: https://developer.github.com/v3/oauth/#scopes.
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.
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.
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.
OSRC: https://github.com/dfm/osrc
OSRC: https://github.com/dfm/osrc
The page is not scrollable so if you're on a small screen and want to see the rest of the image then here it is: https://githubreportcard.reflect.io/images/screenshot.jpg
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 gave me:
- 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.
- 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.
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.
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.
> We're experiencing unusually high traffic so we'll email you when it's complete.
That's a nice touch!
That's a nice touch!
same here. are you still having the same problem?
Not sure if anyone else is getting this, but I can't seem to scroll down past the fold for the site on Chrome on my Windows 7 machine.
Tried using Internet Explorer 11 and nothing showed up at all...
Tried using Internet Explorer 11 and nothing showed up at all...
Yeah, it's just poor UX on their part. The "report card" that you see is actually a screenshot cropped from the bottom.
I think you're seeing the whole page... it's a cropped screenshot.
It wants the ability to WRITE to my public AND private repos & create issues. no. just no.
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.
Shouldn't have used OAuth then.
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.
Public repos are public. All relevant information is available without any action from the owner.
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.I am weary of having managers that might be somewhat incompetent being given a tool like this to help manage developers.
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.
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)
The main page sticks when trying to scroll all the way to the bottom. Running Safari Version 10.0.2 (11602.3.12.0.1) on OS X 10.11.6 (15G1212)
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).
[0]: https://githubreportcard.reflect.io/images/screenshot.jpg
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
What is the difference between Reflect and and something like Power BI? They both have embedding, apis, designers, etc.
Is there some way I could use this for our private Github? Would be interesting to see those numbers.
This application does, for some reason, require write access to all of mine and my organisation's repos.
Just no.
Just no.
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.
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.
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.).
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.
[1] https://www.datadoghq.com/blog/2016-07-08-security-notice/
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/
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).
Might as well just publish https://i.sli.mg/d3m2MD.jpg
More constructively, people should publish the projects they worked on, not how often they press save.
More constructively, people should publish the projects they worked on, not how often they press save.