New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an explanation why OpenCollective needs write access to GitHub repositories #1034
Comments
hi @devurandom you can see this ticket for the history if this issue : #355 |
I'm leaving this ticket open because pointing to #335 or at least an explanation from the auth page is a good idea. |
I would actually argue it shouldn't be "explained" but it should simply never ask for write permissions to git repositories. I consider tihs very dangerous and would certainly never authorize any third-party entity/organization to write to my repositories. Even more so if there's one entity that's collecting write access to repositories of a large number of users and organizations. It's a single point of failure, securiy-wise. |
we don't need write permissions just read. see this issue: #355 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Someone would need to check whether anything changed since May and update this ticket accordingly. |
@devurandom removed the stale flag We effectively need to review the permissions and either: a) we need the extended permissions and we explain why. (on backyourstack for example, we had no choice, https://github.com/opencollective/backyourstack/blob/master/FAQ.md) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is a important issue for any organisation that deals with security critical projects. For example, this issue is stalling adoption in this particular project. PS: Either the stale bot needs to chill down or you need to fix issues faster 😜 |
@hrj Reopened! We and many others have a conversation with GitHub on that topic. The problem is that their permissions system is unflexible. In the end, if it's just to apply on Open Collective, they can just contact support and we will help them without using the GitHub flow. |
You could just use separate OAuth consumers for user identification and for repo identification. The help text for the connect button says "Connect a GitHub account to verify your identity and add it to your profile" if that is truly what you need the access for, (no scope) should work fine. |
Another facet of this issue is, the project I want to sign up with isn't specifically security concious, but one of the other orgs IS, and it looks like permissions are granted to all that allow third party applications, regardless if needed or not. |
How should I go about doing this? |
Usually, it's up to the user to allow/disallow the app to access organizations. It's in the GitHub connection screen. Feel free to contact support https://opencollective.com/support |
That not entirely correct. It depends on the rights that a user has on a given org. I have many admin rights on many orgs, and the latest process requests read access to my orgs private boards. I cannot do this especially when this is about not only private but also third-party data. See also #355 (comment) As a result I cannot apply directly through the UI to the OSC. Not that all my public data are public and readable so I am not sure why OC would need any special rights to access my data... they are already accessible openly. |
This might be fixed soon! |
When I try to connect my OpenCollective account with my GitHub account, GitHub informs me that OpenCollective requests write access to all my public GitHub repositories. This appears to be a bit much. Could you please explain why this is necessary? And possibly add this explanation to the OpenCollective "Connected Accounts" settings page next to the "Connect GitHub" button?
The text was updated successfully, but these errors were encountered: