Download from Github Package Registry without authentication

The repo scope doesn’t actually fix the larger issue for open source projects –
The scope is great for private repositories, but it shouldn’t be required for a public one.

I agree, scopeless tokens should grant read-only access to public information. Unfortunately this isn’t the way it’s implemented at the moment.

This prevents open-source projects from relying on github artifacts, as we can’t rely on everyone having a github token set up for their projects. :frowning_face:

I’ve created a workaround for this that allows PATs with the read:packages scope to be included in public projects. The idea is to encode the PAT so that it isn’t automatically deleted by GitHub when pushed to a public repository.

If you have docker installed, you can use it like this:

$ docker run jcansdale/gpr encode READ_PACKAGES_TOKEN

An encoded token can be included in a public repository without being automatically deleted by GitHub.
These can be used in various package ecosystems like this:

A NuGet `nuget.config` file:
    <add key="Username" value="PublicToken" />
    <add key="ClearTextPassword" value="&#82;&#69;&#65;&#68;&#95;&#80;&#65;&#67;&#75;&#65;&#71;&#69;&#83;&#95;&#84;&#79;&#75;&#69;&#78;" />

A Maven `settings.xml` file:

An npm `.npmrc` file:

This is a bit of a hack, but it does seem to work. You can find a Maven example here:


Pretty shocked that this wasn’t a requirement for the initial release of Github Packages. Thanks for the cool workaround, @jcansdale. To be honest though, I think I’d rather just switch to another package repository than ask all users to implement the workaround. Looking forward to when this is fixed.

1 Like

Having this fixed would be very useful for open source projects, since in conjunction with Actions, it becomes viable to use GH for source code management, continuous integration and distribution. This means one would need no external dependencies to bootstrap a new OSS project.

Especially on the JVM this would be quite nice to have, since the current de-facto standard platforms - Sontatype and Bintray - are not great, each in its own way.

1 Like

Please fix this, forcing people to authenticate to read a public package is ridiculous. Why was it even designed like this in the first place? Why would you even bother implementing an entire authentication system that no one asked for and serves no purpose? What’s stopping you from taking it out? Is it some weird technical limitation that makes it easier to have a full authentication system than to just not have one? I literally can’t think of a single legitimate reason why anyone would think to design it this way, let alone how it got all the way from the design stage to actual production. The only reason I could think of is to boost Github account creation by requiring everyone who wants to use packages to have an account, but I really hope that’s not the direction Github is going in.


Please list me as yet another +1 for this. I found GitHuib Package very easy to produce Android AAR for my GitHub opensource projects, but no, this cannot be used by others as their gradle dependency when the token must be placed.

1 Like


For gradle, you might able to distribute a PAT with the read:packages scope like this:

repositories {
    maven {
        name = "remote"
        // Adapt the URL for your remote repository
        url = uri("")
        credentials { 
            // Use this if the repo requires auth 
            // see
            username = "token"
            password = "\u003c\u0050\u0041\u0054\u003e...................................................."

Here’s how it works:

  1. Create a PAT with the read:packages scope from a safe account (e.g. a machine user account)
  2. Use docker run jcansdale/gpr encode <PAT> to encode the token (see here)
  3. Add a credentials element to the maven details with username and password
  4. username can be anything and password the encoded string from example .npmrc file

I know this isn’t ideal, but at least it means that everyone that needs to build your project doesn’t need to generate and install their own PAT!


Thanks, it’s definitely better than nothing. It’s still a lot of irrelevant boilerplate to be added to end-user gradle script.

And another problem when working on this on GitHub: I’d like to prepare package generation for a repo that is not mine. So, the idea is that on my fork I do all the changes, create a pull request, … and what? It’s not enough to accept the PR. Some extra changes must be done in the context of the upstream fork for the repo to start supporting maven.

1 Like

Can we get an update when this will be fixed properly?

Yet another +1 +1 +1 +1 +1 +1:infinity:

While I do (sort of) see value for private repos, forcing to authenticate before being able to download any package (java, .net, js, etc.) is a real showstopper for public/open source repos.

Please consider what this means from the package consumer perspective: they have to configure another repository source AND also have to have a GitHub account before being able to use the package?!? This will not only annoy the individual users but will also create a lot of friction with corporate DevOps and infra teams, ultimately reducing their willingness to use our packages.

I think the Github Package Registry is a great idea! It streamlines the dev/release process and provides a centralized repository almost language agnostic (Python package support is coming soon, right?) but the forced authentication cripples its usage.

Until this bug is resolved, I think you’ll find adoption won’t be as good as it could be.


Yikes!!! Just spent a day setting up actions to do ci build/test on git push and nuget package creation and publish on release for an open source dotnet project and got it all working and then… shot down in flames!

The only thing wrong is that the public can’t access the public package. Wish I’d known that before I started.

If you aren’t going to be fixing it any time soon can you at least update the GitHub Packages docs to mention somewhere near the top that there’s no non-authorized public access to packages? That would be a really helpful task that can be done quickly and easily.


Can someone make a guide about how to use PAT? Should I generate it myself?


Go to and specify what the token can do (probably read:packages and write:packages)

You’ll need the read:packages scope to restore packages (public or private), or the repo, read:packages and write:packages scopes to publish packages.

I have a lot of concerns about this strategy causing people to publish keys with privileged tokens.
It’d be a really easy mistake to make, given the advice in this thread.

This really deserves more attention – unnecessary security workarounds introduce vulnerabilities.


That’s really unfortunate. Would really like this to be a lot clearer in the docs. It makes no sense to create the packages in a lot of repos, if people cannot simply use it as a dependency.

This is truly ridiculous.

Github’s own popular super-linter project pushes to and pulls from Docker Hub by default. It also pushes to their own package registry, but it can’t pull from there without forcing people do do shenanigans in their workflows. If you look this commit on their action.yml you can see they start using the Docker Hub image instead of it being rebuilt every time. This would have been a natural place to dog-food their own registry, but…


True anonymous access will be coming to GitHub’s container registry relatively soon.

Does it apply to the package registry as well, to e.g. Maven?

1 Like

Eventually, but container registry support will be released first.

Is there any timeline for this?

As I’m currently looking into publishing my first few repositories from their currently private state, it would be interesting to know whether I should just wait for this or publish the maven artifacts elsewhere.

Thank You.

1 Like