Download from Github Package Registry without authentication

Dear Github, well, this is at least silly. Please let everyone use the GPR without authentication as well, it just doesn’t make sense!


Register application

Is there still no solution for this problem?

1 Like

Is there any updates on this issue? When it is expected to be fixed?

Authentication make me hard to use these package in CI environment…

1 Like

any updates? i think this more important than the icons update


I will also switch to a different solution, because of this limitation

I’ve held off on adopting packages because of this limitation. Otherwise it looks great, especially combined with Actions. Hoping it gets addressed soon.

That’s what I would like to avoid, storing my access token that gives full write access to all repos, releases, etc… in my account, in a plaintext file on my laptop.

The repo scope isn’t actually required. You can create a .npmrc file in your respotory like this:


You can then set GITHUB_TOKEN with a PAT that only includes only the read:packages scope. You should find this will allow you to restore both public and private packages.

Please let me know how you get on!


Wow, thank you for adding the new scope!
At the moment of writing there was no such option (you won’t find it for example on this official screenshot here), and an attempt to install packages resulted in a non-ambiguous message that the token must have a repo scope. So, for me it’s 100% fixed.

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.

You don’t need a github account to clone a public repo. You don’t even need to be logged in to manually download the build artifacts from the website. So it’s odd that you need a token to download the artifact from the registry with maven or similar tools.

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:


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.


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.