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.

[tcurdt]

TBH it does not help. With a quick pointer to the fact that this hasn't improved in the past 5y.
The whole token and auth story at Github is abysmal.

[6f6d6172]

Almost five years later and Github Packages can't be interacted with via a Github App despite it explicitly having a Packages permission. Naturally, the "Learn More" link takes you to a section of the documentation that doesn't exist. 🙄

You can't even take the service account route here because Fine Grained PATs also can't be used to interact with the Packages API.

For folks looking for a workaround, this is what I ended up doing for Rubygems:

• Set up an API key with releases:read permission (app/fine grained token should work)
• Find your release by tag
• Get the asset ID corresponding to your .gem file
• Download that asset
• Install that asset manually

This may work for other package types too.

@francisfuzz please consider updating the documentation or the app permissions page so people don't waste their time trying to interact with an API that doesn't exist. Right now interacting with packages via a token generated by an app returns a 403 which is absolutely the wrong HTTP code to be sending here.

[Time0o]

@francisfuzz I concur. This cost me hours of my life today. Not having this functionality would be merely disappointing but pretending that it exists when it does not is unacceptable

[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.

[megquirk]

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?

[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!

[vn7n24fzkq]

This problem still exists. I was stuck on it for 3 days until I found this thread.

[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.

[ycsh-w]

Just encountered the same question and finally got here. It's a bummer that Github Packages simply does not support such an obvious use case.

[project0]

Me, a couple of months ago: Oh! i cannot use my github app credentials for packages/containers in my enterprise org? Hope that gets fixed soon 🤞

Me, today: 😞, I will visit this thread in the future again....

[kaizokuoniorewanaru]

maybe in another five years? 😠

[tcurdt]

Probably not even in 5y. The Github core product feels like abandonware these days.
Acquisitions are the common nail in the coffin.

"Go and use Azure instead!"
I bet that's what it is.

[venkatamutyala]

Probably not even in 5y. The Github core product feels like abandonware these days. Acquisitions are the common nail in the coffin.

"Go and use Azure instead!" I bet that's what it is.

I've actually heard rumors the Azure DevOps folks are going to eventually have to migrate to GitHub.

[evilhamsterman]

It's not related to to AI so it doesn't matter

[sebastianfeduniak]

I have the same issue. I can't believe this isn't implemented.

[Fgruntjes]

:'(

[mtparet]

It's now almost a bug and not a feature.

[DerPurp]

Hell yeah, MT... being solo-dev free-tier I just get to grumble from my "Community" hobo train boxcar.

[mtparet]

Answer from support :

GitHub Packages presently only supports authentication using a classic Personal Access Tokens (PATs) at this time.

While we don’t currently have that paved path functionality implemented, I have reviewed internal requests and have found an associated feature request and have included your feedback on the internal Issue which is used by our product management and engineering teams to track demand. Unfortunately, we do not have an estimate on when the work associated with the internal issue will be triaged, scheduled or implemented.

However, as the issue is known and requires an engineering resolution, I'm going to update the status of this support request to Solved. Please note that this is simply a state within our support system, and does not reflect the state of the internal issue with our Engineering team.

The team may be follow the GitHub Public Roadmap into the future. Some historical references from the Roadmap regarding fine-grained token support for packages includes:
Packages support for fine-grained PATs #558
Packages: Granular permissions and easy organization sharing for enterprise customers #560

[ghazyami]

Same thing was said two years ago https://github.com/orgs/community/discussions/24636#discussioncomment-6154718

[DerPurp]

@mtparet well at least you tried wd... I don't know what it is with GitHub. It's like they fired their entire API development team in 2019 and suddenly all work stopped; everything has remained static based on whatever state it was that Wednesday when they set fire to the API development portakabin.

Fine-grained PATs are themselves kind of part implemented - often wrongly documented - and packages API just never got the same treatment as the rest of the API with regards to GH Apps and ephemeral token usage. Personally I've never found any case where FG PATs are not broken and had to revert to "traditional" PATs. Regardless any PAT regardless of how fine-grained is evidently not the solution. It's not how any of this should work. We need a service-based ephemeral token security solution.

Any questioning of this is, as you've demonstrated, is bounced off by support referring to this mythical "roadmap" which only seems to deliver cool AI-centric "features" that nobody wants and banner ads for those AI features across the site. Just bewildering.

[binarytemple]

Hear, hear 100% it’s an absolute shambles

[ghazyami]

Amazing how this is still not implemented.
Internal feature request open for it mentioned here https://github.com/orgs/community/discussions/24636#discussioncomment-6154718 and here https://github.com/orgs/community/discussions/24636#discussioncomment-13606875

[project0]

@ankneis I do not see any progress in the pubic roadmap, it has been even removed from it and ist just kept stale: github/roadmap#558

[gburke-ppb]

Yeah, we definitely need this. How does one get another note added to the internal ticket to help bolster the demand ?

[kaizokuoniorewanaru]

The reason why this is not implemented is obviously not lack of prioritization or hands to implement it.

It's because GitHub wants GitHub Actions to remain the only CI system that can push to GHCR with temporary tokens.

[tcurdt]

99% of the people only need external READ access. And if you really want there is that PAT. So I am not sure that's a valid angle.

[kaizokuoniorewanaru]

If they implement this for read, what disclose-able excuses would they have left for not implementing write?

[kaizokuoniorewanaru]

Especially now with things like https://github.com/apps/octo-sts, that allow you to delegate the management of the GitHub App private key, it would be very easy to push to GHCR without a static credential

[nafpliot]

The funny thing is that using the ${{ secrets.GITHUB_TOKEN }} in a workflow as answered, doesn't work for getting releases from different repos in the org. It only works for the same repository where the workflow is ran.

So, in your pipeline, you might be having two perfectly good GitHub authentication methods (${{ secrets.GITHUB_TOKEN }} and a GH App) but you need a THIRD one (a PAT) in order to pull a release.

Perfect... 🤷‍♀️

[O5ten]

I'm also a little disappointed in that packages:read isn't supported by github apps. It makes it impossible trying to argue using github packages against someone really pushing ACR or ECR that supports for example workload-identity or Aws IRSA to pull images.

I would be more than happy using a federated identity towards github like it is done on the other way around when i want to push to ECR using github actions with openid connect.

https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws

[0xEthamin]

2025 still asking it please

[AndriiTsok]

Hello community! Any update/plans for allowing Github Apps to access to write to GitHub Container Registry?

[pkazi]

Found this thread after wasting 6 hours in troubleshooting why my GitHub is app not able to pull the oci artefacts (helm chart) from the ghcr.io.

Unfortunately, even AI/GPTs weren’t aware of this open thread 😄 and kept suggesting various debugging steps.

[project0]

@francisfuzz do you know what is the state of this "feature" request? I have the feeling github just stopped working on finalizing the new fine grand access token permissions...
And yes, i requested this already via enterprise support years ago without luck so far.