How do "org level permissions" act on a GitHub App configured for specific repositories?


#1

N.B. These questions are about the GitHub end of the functionality, not the recent real world case :slight_smile:

We recently received a request for expanded permissions for a GitHub App we have already authorized for use in the ‘mozilla’ org. We only authorize use on a per-repository basis. From the outside, it looks like these permissions might expand the amount of PII shared with the GitHub App, particularly for folks who have opted-in to less exposure.

I assume the following two permissions are “per repository”:
Read-only access to Deployments
Read-only access to Commit statuses

Q1: Am I correct about the scope of those permissions?

For the last requested permission:
Read-only access to Organization members
I have several questions:

Q2: Would this allow access to org members who are not explicitly authorized to a subscribed repository?

Q3: For members who have set ‘private’ status in the organization, would their membership be conveyed to the GitHub App?

Q4: For members who are explicitly authorized to a subscribed repository, would the GitHub App have access to their real email address, if they’ve elected to ‘keep my email address private’?

Q5: If the answer to any of Q2, Q3, or Q4 is “yes”, is the GitHub App aware of the distinction and/or required to preserve the intent of those enhance privacy settings?

Thanks!
–Hal


Privacy practices with GitHub apps
#2

Yes.

Yes, organization membership permissions are not scoped to the repositories in which the GitHub App is installed, they’re scoped to the organization itself.

Yes, the GitHub App has read and/or write to all membership information.

I will need to verify this, but as far as I can recall, “No”.

If an owner of an organization would have access to the membership data, then a GitHub App would also have this, given member read access, and per my recollections, “keep my email address private” keeps it hidden from org admins.

At the moment, no. If the distinction is important (and it sounds like it could be), then this is something that should be addressed at the API/permissions level rather than handled by integrators. I don’t know if this has been discussed previously, but it’s certainly worth discussing now.


#3

I’d like to include this point in the permissions discussion you propose below. Something isn’t feeling “consistent” about this.

You’re right - as an organization owner, I can not see email addresses marked as private.

Sounds like a plan – shall we keep the discussion in this topic, or start a new one?


#4

I think that consistency is a question of framing. My gut feeling is that we may need two different types of permissions, one which is a subset of the other, though obviously that’s not a call that I can make offhand in a forum post :)

shall we keep the discussion in this topic

Let’s keep it here. I’m also following up on this internally with the team who works on this.


#5

I think I mostly agree, but I can’t find the Venn diagram markup for this tool, so I’ll have to try words.

Here’s how I’m thinking of it. If an organization makes the explicit (and expensive in terms of admin time) choice to not enable a GitHub App for the entire organization, then they are making a statement that they do not want that GitHub App to have access to all the organization’s assets.

If that GitHub App later asks for access to an “org level” resources, the org is now faced with a choice:

  • stop accepting any updates of functionality
  • give access to org wide resources, contrary to their original intent.

I can see two easy-for-me-to-understand solutions to start the discussion:

  • allow an org to accept or decline permissions individually (and accept that not all features may work with that combo - this is analogous to app permissions in iOS)
  • only expose data that is consistent with the intersection of all the scopes (in this case, only org members who are explicitly granted access to any of the enrolled repositories[1]).

Either of those would provide “consistency” in this case - at least the way I’m using the term. I would, of course, prefer the second, as it’s less work for me, and doesn’t require me to revisit decisions I’ve already made. :wink:

For me, this is similar to the other questions about “preservation of intent to remain hidden” for individual members. My opinion is that the intent should be preserved. Again, I see two ways to start the discussion:

  • GitHub preserves the intent by filtering what data is returned in any query to the GitHub App, or
  • GitHub App developers are explicitly required to preserve the intent (via “acceptable use” or some other document), and all related queries return both the data & the privacy intent.

I believe OAuth Apps essentially use the first approach - at least as far as public vs. private repositories go. I’m not sure how GitHub Apps behave for repositories – it looks like “all repositories” means both public and private.

I’m sure there are other ways to view both cases, and there are real tradeoffs in functionality and administration. I’ll be interested to hear the team’s feedback as well.


[1] that group would be the “set of all active users of their GitHub App”, which is a reasonable group for an app to want access to. I can not quickly think of a reason for an App to have access to lists of folks who do not use their App.


#6

Thank you @hwine, it’s helpful to hear your thoughts around your use case.

I’m not the right person to dig into the questions around decisions about permissions, but I can speak to a couple of your questions.

OAuth Apps essentially use the first approach

OAuth apps literally act as an individual, using the intersection of what the individual has access to, and the scopes of the token in question.

I’m not sure how GitHub Apps behave for repositories – it looks like “all repositories” means both public and private.

Correct. GitHub Apps do not act on behalf of an individual. Where an OAuth token with “write:org” scope would be able to read and write organization and team memberships in all of the organizations where a user is an administrator, a GitHub App has permissions on the organization or repository that it is installed on. So if you have “Issues: read & write” installed for an entire organization, that’s all the issues, whether they are in public or private repositories. If you install it on specific repositories, then again it doesn’t matter whether the repositories are public or private, it would have access to the issues wherever it is installed.

I’ll be interested to hear the team’s feedback as well.

As am I. This is a meaty topic with real trade-offs, and I’d like to understand all the various nuances and implications.


#7

@kytrinyx - now that the dust from GitHub Universe has settled a bit, any update on this?

It does remain an open question for us.


#8

:wave: @hwine. Thanks for following-up. We’ve had some more discussion about this topic as a team. I appreciate the questions you’ve raised here, and I’d like to share how we’re thinking about this topic.

Organization-level permissions are designed to be applied at the organization level regardless of the repository access selected. The repository access that you choose (all or selected repositories) is only relevant to the repository-level permissions, while the organization-level permissions always apply to the organization in which you chose to install the app.

Restricting org-level permissions to just the resources that are relevant to the selected repositories is something that would likely result in a confusing and complicated experience. In theory, it could be applied to something like organization members relatively intuitively, but something like organization projects couldn’t be easily filtered in the same way. In many cases, we also provide a repository-level permission that corresponds to organization-level permissions. For example repository administration would be a decent equivalent of organization members and similarly with the repository projects permission.

In reviewing your questions, I see that there are definitely places where we can make this difference between repository-level permissions and organization-level permissions clearer, so that’s likely something we’ll look to optimize.

I hope this sheds some light on your open questions :smile:.


#9

@jmilas - thanks - I hadn’t thought about that perspective. (I haven’t interacted much with projects.)

And, yes, it’s a messy Venn diagram at best :slight_smile: Good luck with the clarifications.

I’m going to split out my second question (about propagation of private members), as that no longer seems related. [edit: new question]

Have a great weekend!
-Hal