4 ms·

This is a much bigger problem than Heroku. There are countless SaaS applications asking for full-repo access to Github (all the source code, with write access

This is a much bigger problem than Heroku. There are countless SaaS applications asking for full-repo access to Github (all the source code, with write access). - Productboard - Bugsnag - Sentry - Skylight - Percy - CodeTree - Databox There are heaps of others, these are just some on top the of my mind. A ticking supply chain attack waiting to happen, since these companies make themselves into alluring hacking targets. Most of them need access only to issues (a few need read access to code or recent commits, almost none need write). Solution: - Let customers give granular access (only issues, only read to source code, etc) when the integration is setup. This is possible with Github's APIs. - Try to use push instead of pull where possible, i.e. provide a CLI tool to use with Github actions or use Github's webhooks.

the_mitsuhiko 4y ago
> There are countless SaaS applications asking for full-repo access to Github (all the source code, with write access). Sentry does not request write access to source code. It requests read/write access to issues and read access to source code. You can also see this on the documentation for the GitHub enterprise integration which lists the exact permissions required: https://docs.sentry.io/product/integrations/source-code-mgmt/github/ https://docs.sentry.io/product/integrations/source-code-mgmt...
- sandstrom 4y ago
  Thanks for clarifying. It would still be better if I didn't have to give read access to source code, but could still use the issues integration. But I agree it's not as a bad as write access to source code.
  - michaelbuckbee 4y ago
    Most error monitoring services want this as they map errors to commits.
    - dharmab 4y ago
      As a user it's nice to have the option of foregoing the feature.
      - orf 4y ago
        Then just don’t link it to GitHub if you don’t want your errors tracked back to specific commits?
        dharmab 4y ago
        I might want it linked to my issues but not my source code.
    - sandstrom 4y ago
      I know it's more work, but they could also use Github Actions to push recent commits (past 90 days) to themselves, and use them. That way they wouldn't store or have access to all source code.
jrochkind1 4y ago
For a while now I've been worried about this -- either integrations asking for full read/write access for a service that might seem to need only read. Or maybe worse, integrations asking for access to anything my account has access to, when I only want to grant it to one repo or organization, or only to public repos and not private ones. Whenever I've reached out to inquire/complain about this, I've been told that github does not give them granular enough auth settings to ask for less than this. Is this true? I don't know. When I've tried looking at the relevant github docs myself, i quickly get confused. Does anyone understand the github auth architecture -- does it need to be fixed to allow more granular access, or are integrations just not using it properly? Like... who should I be complaining to?
- whelton 4y ago
  I've been looking into this as I'm building similar per resource scoping for conjure.so's API. GitHub has 'OAuth Apps' and 'GitHub Apps' [0]. The former's scopes do not permit such granularity (eg the `repo` scope gives access to all repos of the account [1]). The latter is much more granular, allowing the user to select specific repos to grant permission [2]. The 'GitHub App' owner can see their installations and also determine if the user chose access for all repos or on a per repo basis. Netlify does such granular installation and will prompt you if you don't see your repo listed in their dashboard to check permissions. [0] https://docs.github.com/en/developers/apps/getting-started-with-apps/differences-between-github-apps-and-oauth-apps#what-can-github-apps-and-oauth-apps-access https://docs.github.com/en/developers/apps/getting-started-w... [1] https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes https://docs.github.com/en/developers/apps/building-oauth-ap... [2] https://docs.github.com/en/developers/apps/managing-github-apps/installing-github-apps#installing-your-private-github-app-on-your-repository https://docs.github.com/en/developers/apps/managing-github-a...
  - ethbr0 4y ago
    Ironically, Slack seems to have really homed in on granularity of integration access as a key feature as well. Which makes sense... but then so many companies don't do that.

the_mitsuhiko 4y ago

> There are countless SaaS applications asking for full-repo access to Github (all the source code, with write access). Sentry does not request write access to source code. It requests read/write access to issues and read access to source code. You can also see this on the documentation for the GitHub enterprise integration which lists the exact permissions required: https://docs.sentry.io/product/integrations/source-code-mgmt/github/ https://docs.sentry.io/product/integrations/source-code-mgmt...

sandstrom 4y ago
Thanks for clarifying. It would still be better if I didn't have to give read access to source code, but could still use the issues integration. But I agree it's not as a bad as write access to source code.
- michaelbuckbee 4y ago
  Most error monitoring services want this as they map errors to commits.
  - dharmab 4y ago
    As a user it's nice to have the option of foregoing the feature.
    - orf 4y ago
      Then just don’t link it to GitHub if you don’t want your errors tracked back to specific commits?
      - dharmab 4y ago
        I might want it linked to my issues but not my source code.
  - sandstrom 4y ago
    I know it's more work, but they could also use Github Actions to push recent commits (past 90 days) to themselves, and use them. That way they wouldn't store or have access to all source code.

jrochkind1 4y ago

For a while now I've been worried about this -- either integrations asking for full read/write access for a service that might seem to need only read. Or maybe worse, integrations asking for access to anything my account has access to, when I only want to grant it to one repo or organization, or only to public repos and not private ones. Whenever I've reached out to inquire/complain about this, I've been told that github does not give them granular enough auth settings to ask for less than this. Is this true? I don't know. When I've tried looking at the relevant github docs myself, i quickly get confused. Does anyone understand the github auth architecture -- does it need to be fixed to allow more granular access, or are integrations just not using it properly? Like... who should I be complaining to?

whelton 4y ago
I've been looking into this as I'm building similar per resource scoping for conjure.so's API. GitHub has 'OAuth Apps' and 'GitHub Apps' [0]. The former's scopes do not permit such granularity (eg the `repo` scope gives access to all repos of the account [1]). The latter is much more granular, allowing the user to select specific repos to grant permission [2]. The 'GitHub App' owner can see their installations and also determine if the user chose access for all repos or on a per repo basis. Netlify does such granular installation and will prompt you if you don't see your repo listed in their dashboard to check permissions. [0] https://docs.github.com/en/developers/apps/getting-started-with-apps/differences-between-github-apps-and-oauth-apps#what-can-github-apps-and-oauth-apps-access https://docs.github.com/en/developers/apps/getting-started-w... [1] https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes https://docs.github.com/en/developers/apps/building-oauth-ap... [2] https://docs.github.com/en/developers/apps/managing-github-apps/installing-github-apps#installing-your-private-github-app-on-your-repository https://docs.github.com/en/developers/apps/managing-github-a...
- ethbr0 4y ago
  Ironically, Slack seems to have really homed in on granularity of integration access as a key feature as well. Which makes sense... but then so many companies don't do that.