GITHUB_TOKEN cannot access private packages

I am also interested in a soltution here. Currently we are also using PAT to read private organization packages.

It looks like the GITHUB_TOKEN permissions feature has been added: GitHub Actions: Control permissions for GITHUB_TOKEN | GitHub Changelog

but I don’t see anything about OrganizationPackages as this prior post seemed to indicate:

Also can’t find anything in the docs about it.

Looks like this is still an issue?

I haven’t investigated the new Control permissions, so I don’t know if that fixes the above problem or no. I’ve put it on the list of things to do.

In general, I have used a GitHub App and this action (GitHub - tibdex/github-app-token: Impersonate a GitHub App in a GitHub Action) to dynamically generate PATs when I need them, to decent effect.

It’s not solved. The new github token permission per-job settings is great, but it’s missing the organization level stuff still.

We’re publishing a maven package in another private repo, and depend on it in the project at hand. It seems impossible to setup maven so that github actions can build my project because of this dependency.

1 Like

You are correct that the GITHUB_TOKEN is only going to have permissions in the repo that triggered the workflow. That is for security reasons. You will have to generate a PAT to use to access information in another repository from that workflow.

So (just to confirm), there’s no planned support for org-level GITHUB_TOKEN’s before the 4 August deadline?

3 Likes

Github staff keep talking about this being a security thing, but the “solution” of using a PAT is just straight up worse for security than being able to use a properly scoped read-only token for org-wide packages.

10 Likes

@ethomson for more than 2 years this problem persists. There is still no valid solution for the problem, or a good enough workaround (PAT doesn’t work, since it provides access to also private packages, which is not secure).

Can you please provide a thorough response on why wasn’t it implemented, what is the official way of solving it and ETA for the solution. As the problem here is definitely not code-based, please also make transparent the reasons it wasn’t done yet.

I am sorry for being crass, but this is bullshit. there is no security problem with adding another permission called, say, organisation-packages, and giving it the permissions.
Creating a PAT is less secure: it provides access to ALL repositories the user has, not only to this organisation.

2 Likes

@mickeygousset as blunt as Igor was, he is correct. We’ve had to work around this issue for over a year and just because I’m not constantly bumping this thread, it doesn’t mean it’s still not an issue for our organization, I just feel that with all the feedback already provided, it seems futile.

The only secure workaround we know of is creating an additional github user account which only has access to the organization’s repositories and creating a PAT to provide access to them (and only them).

Creating these fake/shadow user accounts for this purpose not only is confusing, costs additional monthly license fees, but is also less secure as it’s another account that needs securing and maintaining.

2 Likes

Hey @yhaskell @danrivett: I always appreciate blunt feedback.

Have you tried creating a GitHub App, and requesting a token from that app? That eliminates the need for a service account, as mentioned by @danrivett. And yes, while that is still a PAT, it is a little more controlled.

Unfortunately, I don’t see anything on the public roadmap around this. And I don’t have insight into the technical debt/issues that might prohibit adding security permissions to the token.

I’m gonna take the link to this thread and toss it out internally and see if I can get some responses on why it is this way, any other options, and anything that might be coming. I’ll report back.

meh, it could be that GitHub App tokens also don’t work. I haven’t tried it yet. I’ll try and confirm that as well.

@yhaskell @danrivett

Ok, here is what I have learned that I feel I can say publicly. I will apologize in advance for any vagueness, but at this point its the best I can do. I’ve conversations with several people to understand the issue, the workarounds, and what is coming. Unfortunately, there isn’t much I can say, but let’s see if what I CAN say helps at all.

First off: Using a GitHub App to generate a token won’t work. The package permissions aren’t there to allow you to scope the GitHub App token. This is something the product team is aware of, however, I don’t have an ETA on when this might be fixed, and there isn’t anything on the public roadmap about it that I saw.

Which unfortunately leaves us with having to use a PAT to make this happen. The product team is aware that this is not ideal. I can’t say more about why it was done this way, or what would have to be done to fix it. You will have to trust me there are some technical reasons why, and that the product team is aware of the community’s concern. This is feedback we have heard from other customers as well, so I added this thread onto that feedback.

As with the GitHub App issue, there isn’t anything on the public roadmap around this yet. As soon as there is, I will come back and update this issue.

4 Likes

I was just about to comment the same thing! Using the OAuth gen token gets you: “This credential type is not supported for registry. Please use a Personal Access Token or GitHub Actions token instead.” Nice helpful error, at least :grin:

Aren’t the package permissions available though?

@arbourd They are, but they don’t seem to work. The product team is aware of that and looking into it.

1 Like

Ya, from a security perspective we would like to be using the OAuth App at least, instead of spending $21/m to have a forever-token just to pull node packages in CI.

Thanks Mickey for following up about this and getting some answers, even if you can’t share much publicly, that’s still helpful.

I will continue to monitor this thread, so if there are any updates in the future that you can share publicly, please do so when you get a chance. It definitely would be a great improvement if this was resolved at some point.

2 Likes

This has just caused us a major PITA. PATs are really not the answer, I work across multiple orgs and I really don’t want to have to open that up using my PAT.

Please push this through asap so that a secrets.GITHUB_TOKEN is org scoped

Wow, this is crazy. I don’t understand the use case for a token scoped to the repo for packages. An org-wide token can at least install reusable code from another repo within the org, which is something we often do. If you are in the same repo, you’re probably using direct references. The github token is, for all intents and purposes, useless.

3 Likes

I have stumbled across this issue myself today and I am amazed how long it exists. It makes GitHub Actions and the NPM repository almost useless. How come this isn’t given more attention? As @mmulhearn said, the packages: read permission might as well give access to the entire organization, as the repository-wide variant is unnecessary. PATs are an absolutely awful solution to this problem.

2 Likes