Read GitHub Packages permission for GitHub App?

[dgholz]

Hello, I’m looking at the list of permissions that an App can be granted and I can’t see one which would allow my app to fetch packages from a repo. Is there a permission I can grant my app to fetch packages from repos/orgs it’s installed into?

[francisfuzz]

👋 Hello, @dgholz ! Welcome to the GitHub Community Forum––we’re glad to see you post this question here. 👍

Permissions on “packages” is not currently available for all¹ GitHub Apps (see GitHub Apps Permissions for more details).

We’re always working to improve GitHub and the GitHub Support Community, and we consider every suggestion we receive. Would you mind submitting this through our official product feedback form so that our product team can track your request?

It may be worth noting that you can use either of these tokens to authenticate with GitHub Packages:

• a personal access token with the read:packages scope.
• the GITHUB_TOKEN that GitHub automatically creates for your repository when you enable GitHub Actions (see About GitHub Packages with GitHub Actions and Permissions for the GITHUB_TOKEN for more details).

We hope this helps!

---

¹ At this time of writing, the GITHUB_TOKEN from GitHub Actions is an installation token associated with a GitHub App owned by GitHub and is the only GitHub App with access to packages.

[dgholz]

Thanks, that’s helpful. I used an Action and its token to fetch packages from my org, but I see today that it’s failing to see private packages (published on other repos in our org). Last week it was working fine, was the scope of the token’s access to GitHub Packages changed recently?

[glloydcorecard]

Would love to actually see GitHub Applications have permissions to Read/Write to packages. We are currently trying to leverage the GITHUB_TOKEN when leveraging a maven parent. However, it fails to download the package. The only solution we have found so far it leverage a user PAT which is not a tenable solution.

Additionally in the workflow we did set the package permission to write and it was still unable to download the package.

[kshiftw]

Github Support confirmed that it is still not possible to authenticate with a GitHub App token on the GitHub Package Registry:

You cannot authenticate with a GitHub App token on the GitHub Package Registry.

This is a pain point for other GitHub users as well and the Packages team is looking into supporting GitHub App installation tokens for authenticating to the Package Registry. There is an open internal feature request for this functionality, I have added your voice to it. This is not on our public roadmap yet, so I do not have a link for you to follow the progress. However, we usually announce such features as they become available on the [ChangeLog](https://github.blog/changelog/) page of our [Blog](https://github.blog/).

If you are using GitHub Actions for your builds, you can use the GITHUB_TOKEN available on each workflow run.

https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions

If not, you'll need to [create a personal access token(classic)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) with the packages scope to access the packages.

[loki666]

It's not clear to me...

Can a workflow running on repo A access the maven package repository on private repository B using GITHUB_TOKEN?

Both repositories are part of the same org.

Thanks

[cs-fokko]

Not clear for me as well. For NPM packages we can set access rights for different private repos in the org but not for Maven. Moreover, the repository information in the registry link is not that relevant as we can insert anything there. The GitHub Maven indexes packages on org level. But we cannot access the packages from actions within the org. It's a real hassle. Right now, I guess, the only solution is a PAT.

[florianmutter]

Giving permission to a different repo does not work for NPM for us

[rowi1de]

https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#github-actions-access-for-packages-scoped-to-organizations

This should work but is really inconvenient:
If you want to pull package of Repo A,
you need to add Repo B (… Z) there to allow access via workflows? In organizations it can be multitude of packages / repositories using each other.

[warrenackerman]

We are having this issue as well. We want to use a git hub app generated token to download packages from our private repositories and it is not working.
I see this issue is over 3 years old with no real updates from Github.
@loki666 the GITHUB_TOKEN I think this will not work since it has only rights to the repo the workflow was triggered from.
@cs-fokko That approach did not work for us. We tried adding individual repos (RepoB in our scenario) to package settings and we were unable to authorize DL of RepoA Packages to RepoB's workflow.

[meghein]

Also having this issue, would love a resolution - anything in the pipeline to fix this??

[garyy7811]

this is an example of usage: https://github.com/orgs/community/discussions/78090

need permissions to access org packages.

[MMartyn]

This is also presenting a problem for me as well. It seems odd that the app token can be used to pull down release binaries but can't pull down packages.

[domgraziano]

Same problem here, spoke with enterprise support today and seems odd that one should use a personal access token instead of an app. Suggestion for support was that this is till the only option available with the added burden that a PAT can only be usable with a seat and you pay for a seat! Plus: for GitHub Apps, the rate limit is 15,000 requests per hour. However, if you're using a PAT, the rate limit is 5,000 requests per hour. I would love to see Github to action a resolution for such a significant limitation in its roadmap.

[acuD1]

Hi, same problems here. Generated tokens from Github App can't pull from ghcr.io.

$ gh token generate --key private-key.pem --app-id <redacted>                                                                                                                                                                               
{
  "token": "ghs_<redacted>",
  "expires_at": "2024-06-11T15:50:57Z",
  "permissions": {
    "actions": "write",
    "contents": "write",
    "metadata": "read",
    "packages": "write",
    "workflows": "write"
  }
}

In the logs we can see that.

docker: Error response from daemon: denied.

But it might be due to the username field. Which username should we put for login to the registry ? (Even though we get Login Succeeded).

[mtparet]

Who is really using GitHub packages ? With the lack of correct permission management, it's just not acceptable to use in any enterprise with a minimum security level required by the business/clients.

It's just for public packages for now.

[benbonnet]

This discussion demonstrates you can't automate much atop github package registry, as it remains manual, so adoption can't even take off.
For now, and for internal tooling, many might want to have it all managed at the same place

[garyy7811]

I think this is on purpose, to keep people using Github workflow to build Github repo.

…

On Mon, Jul 1, 2024 at 10:15 AM Ben ***@***.***> wrote: This discussion demonstrates you can't automate much atop github package registry, as it remains manual. For internal tooling, many might want to have it all managed at the same place — Reply to this email directly, view it on GitHub <#24636 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHMU2QFLYOOGGBG2IZRMQN3ZKFQBVAVCNFSM6AAAAAAZDU3KDOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSMRWGE4TS> . You are receiving this because you commented.Message ID: ***@***.***>

[fcbry]

This 100%

[mjfpalmer]

+1

Really silly that my GitHub app can do everything it needs to using its own access token, except read packages!

[chrede88]

Saw this packages permission while going through one of my Github App's permissions the other day. It's a bit strange, as the help link to a page that doesn't exist: https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-packages

Could it be that this is now "half way" implemented?

[tim-becker]

I'm also confused why this permission exists but doesn't seem to work

[venkatamutyala]

This is exciting. I assume they are still working on it/testing it. So hopefully we will be able to switch over soon than later.

[evilhamsterman]

I can certainly see that they may be testing it, though it shouldn't be listed in the available permissions if it isn't live yet. They have been doing a bunch recently to improve apps, like allowing Enterprises to share apps across their organizations, before we either had to create multiple apps or make apps publicly visible. It would be nice to get a response from GitHub, perhaps I'll reach out to my rep

[fbonander]

I ran into the same thing. Got this response from our GitHub rep.

Unfortunately, GitHub Apps cannot authenticate against GitHub Packages registry. Only the Actions GITHUB_TOKEN and Personal Access Token can do so.
Though the UI refers to GitHub Apps Package permission as "Packages published to the GitHub Package Platform", they can only access Package billing aspects on the GitHub's REST API. I am going to raise this internally towards our Product managers to clarify the UI.

[venkatamutyala]

Dang!

[rowi1de]

What are the current options for organizations with multiple private repository packages:

• Use a PAT of a developer or “service user”
• To use GITHUB_TOKEN, it is required to add every repo to each package that should be able to pull in a workflow? https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#github-actions-access-for-packages-scoped-to-organizations

[DerPurp]

@rowi1de I think you've summed it up. At the very most I've managed to permission a GitHub App, request an installation access token, authenticate - then repeatedly receive no packages; an empty JSON array. Even though the GitHub App is installed in the organisation, has access to all repositories, and is permissioned with package read, content read and metadata read. This appears to totally contradict the documentation.

However whilst your synopsis is true, there's a slightly different way of working which might help you. If it meets your security requirements, you could set your packages to internal instead of private. This would mean that you don't require to add every consumer worklow action's repository to the list on the package security settings page.

You have to first allow internal visibility on the Organisation:

• Organisation -> Settings (the top bar not the cog on the right) -> Packages:
• Packages permissions | Package creation -> Internal, Save

Then set internal visibility on the Package:

• Organisation -> Packages [Top naviation bar]
• Select a package
• Package Settings [Right navigation bar]
• Scroll down to Danger Zone
  • Change Visibility -> Internal

Note that on your organisation package list Internal in a a roundtangle is shown, if it helps you power through changing them and remembering which ones you've done.

Admittedly this isn't for everyone. If you have discrete package access groups within the organisation and wish to proceed with that then it wouldn't be manageable unless you split the organisation.

The solution, if it does suit you is still a bit of work, but all actions across all repositories within the organisation will be able to access the packages with its inbuilt ${{ secrets.GITHUB_TOKEN }}; no hacky, potentially finite, user-specific PATs or repeated single repository checkboxes on private packages.

[acuD1]

@DerPurp Hi, you are talking about GH Actions, but what about Github Apps, is changing the permissions to Internal solves the Githup Apps pull issue ? Ty

[DerPurp]

@DerPurp Hi, you are talking about GH Actions, but what about Github Apps, is changing the permissions to Internal solves the Githup Apps pull issue ? Ty

As an official rule GitHub Apps can't be used for package authentication at all. The underlying GH API /package/ commands fail if you try to authenticate with an installation access token generated from a GitHub App. Some package endpoints simply return an HTTP 403 Access Denied, some return incorrect and potentially confusing data.

If you did have an app used to access a repository externally which has packages exposed internally from a different repository in the same organisation - I haven't tried this specifically but I can't see how it would behave any differently. internal package visibility means that any repository in the organisation has visibility of the package. Given that apps don't even provide access to packages on the repository level, I can't see why this would work at the organisation level either.

This is really down to internal politics within the GH API team. There's no technical reason other than this newer method of access has never been prioritised for implementation in this area of the API. This is reflected on About Permissions for GitHub Packages:

GitHub Packages only supports authentication using a personal access token (classic). For more information, see Managing your personal access tokens.

Given this strict constraint, this is why I advocated using the standard build token accessing another repository in the organisation using internal visibility set on the package as a potential option. This provides access implicitly to the native build token, rather than negotiating via a GitHub App which is officially unsupported. The only other ways you could do it are using a PAT (as documented), or making the package repository public (which of course has far deeper implications). It's frankly quite dangerous as encourages developers to lean towards not only PATs (which should be tied to a single developer) but potentially infinite lifetime PATs.

This is a cause of a lot of contention within the community as shown here. If more developers state that this is a requirement it could cause GitHub to reprioritise its, in my opinion overdue, implementation.

[avpjanm]

+1

GH apps is considered as a best practice for non-personlized access. In my opinion accessing packages is must-have feature.

[davidswimbird]

I can't believe this isn't implemented yet. Why even bother using an app, if I can't use it everywhere?

[DerPurp]

Couldn't agree more. I mean the advantages of apps are huge: not user-centric, no requirement for additional service users; infinite lifetime; asymmetric cryptography. But in the places where you need package access and something else? You'd need an app and an infinite lifetime user PAT. You're just increasing the attack surface let alone vastly complicating maintenance.

There's just no reason other than questionable internal politics and management of the packaging API stream.

[israelbgf]

Hey @DerPurp are you sure that the internal repository is enough to make it's package available to other private repositories? I tried that here in my Org and I'm still having permission errors.

Org Setting

Repo Setting

Package Setting

(the package does not allow visibility change, neither state, I guess it's related to the repo itself)

[DerPurp]

I'm certain that internal package visibility allows a package to be shared across the org. It's something we use extensively. All of your screenshots look familiar and correct.

The repo should be set as private, the repo package as internal, and internal packages should be allowed on the org. Then, the GITHUB_TOKEN on an action should be able to see all of the org internal packages as if the sister repo was public. I don't even recall any nuances like having to republish.

Forgive if anything's incorrect - this is off the top of my head as on my phone and replied for expedience. However all of our repos bar one are private. All of our packages are internal, so I know this works at least conceptually.

Without double checking I do vaguely recall some unintuitive setting on the org which simply allowed repos to have internal packages, but didn't change the visibility. If so, the org and the repo visibility had to change for the package to become internal. If that's any help...

[DerPurp]

@israelbgf Ok oddly enough - I had to just do this myself.

The visibility of the package is specifically in the package, not the repo (which remains private).

To clarify:

• Publish the package from your private repo
• Navigate to Your Organisation
• Select Packages (from the top navigation bar)
• On the Packages screen:
  • Locate your package in your package list
  • [Observe the roundtangle on the right of the package name (Private)]
  • Click on the package name
• On the Package Versions screen:
  • select Package Settings (right hand navigation bar this time)
• On the Package Settings screen:
  • Scroll down to Danger Zone
  • Press the Change Visibility button
• On the Change package visibility dialog:
  • Select Internal
  • Enter the package name in the "Please type ... to confirm" textbox
  • Press the I understand the consequences, change package visibility button

You should now have an internal package viewable using the GITHUB_TOKEN in a GitHub action.
No further action is required (such as republishing the package, changing the action).

[israelbgf]

Thanks for the follow up @DerPurp, good to know that the visibility is related to the package and not to the repo itself. This puts me back in the right track. Unfortunately, somehow I can't the the visibility option:

I'll give a look in the docs and maybe reach to Github support to figure it out. Maybe related to this:

But my repo does have the right visibility. 🤔

[DerPurp]

@israelbgf ah, indeed you might have additionally fallen prey to the organisation settings.

I think the particular setting you might be looking for is the one above what you're suggesting:

• My Organisation -> Settings (top navigation bar) -> Packages (left navigation bar)-> Package Permissions -> Package Creation -> Internal (check checkbox).

This setting should allow you to change the visibility of each package rather than the repo. (I'm presuming that if there are no available choices then possibly within the packages' "Danger Zone", the "Visibility" section is simply - well, invisible - and this is what you're observing.)

What I can tell you is that our organisation has this setting enabled, along with the Default package settings to which you referred, too. I'm quite sure that that setting can stay on the default checked state.

So to recap, on the Organisation settings I would suggest:

• changing the Package Creation setting to allow Internal
• leaving the suggested Default Package Settings/Inherit access from source repository alone

[israelbgf]

Unfortunately, that was correct already:

But I've been doing some reading... it seems that the visibility of a package is ALWAYS attached to the repository WHEN using MAVEN (are you using NPM?). It seems that this "fine grained visibility" it's only available to the non-jurassic package management systems. 😆

I wonder if this means that I need to do some new releases for the permission to "change". Anyway, thanks for the willingness to help so far. Highly appreciated. 👍

[DerPurp]

Ah sh*t. No, we're using nuget and github for building. Then indeed sounds like some good detective work but bar finding some grevious hack you might be scuppered. Potentially I guess there could be some github packages API call you could make, but this is really the extent of my expertise I'm afraid :/ good luck!

[tarunmittal24]

Just having a simple requirement to read a package in the github-actions either using the GITHUB_TOKEN or by any way authenticating by the github app, any way to do it.

[DoisKoh]

I wasted an entire day trying to figure out what was wrong with my configuration. I'm sure there are others out there who had to go through that too.

This needs to be very conspicuously listed in the docs (that GitHub Apps cannot be used to read or write to packages) - the fact that it appears as an option in the permissions makes this all the more egregious.

[israelbgf]

Just to confirm that @DerPurp suggestion, which is perfect for a lot of cases, doesn't work for Maven or Gradle. Github don't support that "internal" visibility for those package managers. I also asked directly the Github Support, so yes, this is very frustrating as it seems something super basic. So neither Github APPs or the builtin secrets.GITHUB_TOKEN will work for those package managers.

Thanks again @DerPurp for the help.

[DerPurp]

Well at least your diligence on chasing this up might save someone a fair bit of time on a murky voodoo topic. Nice one, just wish we could have got a solution in the end :/