Download from Github Package Registry without authentication

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

There isn’t an exact timeline, but I wouldn’t expect anything this year for Maven.

+1 For the utter mess and 2 hours waste of my time Github package registry is without public access.
This should have been specified up front in the docs on this page that “make the package available for others to download” means only those people with an access token.


Oh man this could be so cool. Glad I found this thread. Was about to setup to publish a maven package but if the public can’t access without setting up a PAT whats the point.