I found this issue while diagnosing a similar problem with our merge bot. This change started affecting us somewhere in the last two hours.

Hey @omnibs and @bertptrs 👋

You all caught this well before I could! We did push a recent update (4 hours ago, as of this writing) that now requires admin access via the API to see collaborators.

This change brings our API in-line with the Web based experience, and should be more consistent.

There’s quite an extensive reasoning behind this and if it’s necessary I can elevate those details.

So yes, this was a deliberate action. For now, I don’t believe there is another permissions level outside of admin to perform this action.

Alternatively, it is true that GitHub Integrations have the ability to list collaborators, but we will likely be reviewing that in the future.

Edit: our team is currently in discussion about the impact this might have, and whether or not a reversion is warranted. Will update when there’s more to share.

This change is affecting our merge bot that requires such permission for listing the authorized people to perform such action:

  <a href="https://github.com/OCA/OpenUpgrade/pull/2854#issuecomment-920041953" target="_blank" rel="noopener nofollow ugc">github.com/OCA/OpenUpgrade</a>

<div class="branches">
  <code>OCA:14.0</code> ← <code>ForgeFlow:14.0-mig-im_livechat</code>
</div>

<div class="github-info">
  <div class="date">
    opened <span class="discourse-local-date" data-format="ll" data-date="2021-07-22" data-time="08:51:38" data-timezone="UTC">08:51AM - 22 Jul 21 UTC</span>
  </div>

  <div class="user">
    <a href="https://github.com/MiquelRForgeFlow" target="_blank" rel="noopener nofollow ugc">
      <img alt="MiquelRForgeFlow" src="https://user-images.githubusercontent.com/7165771/181085674-f88b23d3-dfae-46e1-961d-8d3ae1136d3a.jpeg" class="onebox-avatar-inline" width="20" height="20">
      MiquelRForgeFlow
    </a>
  </div>

  <div class="lines" title="1 commits changed 4 files with 43 additions and 1 deletions">
    <a href="https://github.com/OCA/OpenUpgrade/pull/2854/files" target="_blank" rel="noopener nofollow ugc">
      <span class="added">+43</span>
      <span class="removed">-1</span>
    </a>
  </div>
</div>

If such list is public, why it should be restricted to admins?

Was there some warning or notification before this went live? Is there a way to be warned about similar changes which could break tools using the GitHub API in the future?

Thanks

Hi @emin63 👋

Thanks for joining the Support Community to participate in this thread.

Unfortunately, this change was made silently, after comparing the experience with accessing this information via the web UI, and the API. As it was, it was an inconsistent experience where only Administrators could view collaborator information on the UI, but push access could grant these privileges for the API.

In my edit earlier I mentioned we were considering a rollback, but that doesn’t seem likely now.

We should be posting to our blog about this soon. Though I can’t say exactly when.

I have the same problem

I believe this may have also broken the “Get Repository Permissions for a User” API even when a user is trying to access their OWN permissions:
https://docs.github.com/en/rest/reference/repos#get-repository-permissions-for-a-user

I don’t think a user should need to be admin to check their own permissions. Is there any other way for a user to use the API to find out their permission level on a repo?

Hey @hatboysam 👋

I’ve followed the discussion since this morning, and that portion of our codebase (get permission) should not have been impacted. At least, that’s my current understanding.

Would you mind submitting this as a Support ticket? Or if you prefer, we can split this off into it’s own thread.

For now, increasing permissions for these automation tools to admin is going to be the solution.

I’m so sorry for the lack of comms before this was put out, ya’ll. Not the best experience here.

Thanks for the quick response. I filed ticket 1310760 a few hours ago, it has some details. I was able to work around this by using the “get repository” API which returns a personalized permissions field since in my application users only need to know their own permissions.

But it would be great if you could investigate anyway, as I do believe that API is now behaving as I described.

Went back and yes, the collaborators/{user}/permission endpoint for /repos, has also been updated to only allow the owner access to permission details. So if you are a collaborator, you can no longer view this via the API.

Again, apologies for the lack of transparency before this change was made. I myself wasn’t aware until this thread.

We hope to have out a /changelog post soon. 🤞

For now, increasing permissions for these automation tools to admin is going to be the solution.

Requiring admin privilege merely for checking whether a user would be allowed to merge a pull request seems overbearing. This would go directly against the principle of least privilege. This change would mean that bots will have to be guarded against accidentally doing any of the other catastrophic actions that admin permissions would bring.

Bots need a non-admin way to know whether a user can trigger it. The jerk change to suddenly make merge bots admin is going to make them a prime target for attack. No one saw this coming, and suddenly giving merge bots admin access is going to be a huge and very obvious security risk.

Not communicating this change isn’t the biggest problem, the biggest problem here is demanding merge bot users to accept this security liability.

Requiring admin privilege merely for checking whether a user would be allowed to merge a pull request seems overbearing. This would go directly against the principle of least privilege. This change would mean that bots will have to be guarded against accidentally doing any of the other catastrophic actions that admin permissions would bring.

☝️ this; we also got hit by this change, effectively breaking all our Jenkins jobs.

Requiring admin privilege merely for checking whether a user would be allowed to merge a pull request seems overbearing. This would go directly against the principle of least privilege. This change would mean that bots will have to be guarded against accidentally doing any of the other catastrophic actions that admin permissions would bring.

Fully agree. Several Eclipse projects are affected by this as well. See also [cross-project-issues-dev] GitHub issue - "Must have push access to view

Even it is effecting us running prow bot

@nethgato you said this change was made to bring the API in line with the information accessible via the Web UI, but actually it is not.

My use case for this API is to allow users to find someone who can review their code. On GitHub this is done via the Reviewers autocomplete box. This box only allows the user to pick other collaborators and is visible to anyone with write acccess:

So this information is already intentionally visible in the Web UI to anyone with write access. I would really appreciate if the API would give me at least the same ability to list collaborators.

Thanks for reconsidering.

Many Thanks.
Nice solution

Ah, I shouldn’t take any thanks here, but I appreciate how perplexing it must have been to see these 403s out of nowhere and without a changelog to point to.

And I should further clarify (rather than edit my last post) that I should not say “when this comes back up,” but “if.”

We are considering marking this internally as a “won’t fix,” but there are some internal conversations that initially sparked the change, and was fast tracked, without considering the impact on automation tools that leverage those endpoints.

So if it comes back, it will be announced in advance.

Hey @omnibs and @bertptrs 👋

You all caught this well before I could! We did push a recent update (4 hours ago, as of this writing) that now requires admin access via the API to see collaborators.

This change brings our API in-line with the Web based experience, and should be more consistent.

There’s quite an extensive reasoning behind this and if it’s necessary I can elevate those details.

So yes, this was a deliberate action. For now, I don’t believe there is another permissions level outside of admin to perform this action.

Alternatively, it is true that GitHub Integrations have the ability to list collaborators, but we will likely be reviewing that in the future.

Edit: our team is currently in discussion about the impact this might have, and whether or not a reversion is warranted. Will update when there’s more to share.