Listing Docker Tags in GHCR without Authorization?

[fabianvallon-db]

🏷️ Discussion Type

Bug

Body

Hi,

I wanted to list available docker tags of renovate. Following the OCI specification this should be possible by calling https://ghcr.io/v2/renovatebot/renovate/tags/list - However I get the following response:

{"errors":[{"code":"UNAUTHORIZED","message":"authentication required"}]}

Even with a user token with scope read:packages the same message gets returned.
Since renovate is a public package I was wondering why the tag listing requires authentication at all.
Is this a bug or does GHCR have a specific dialect of the OCI protocol that I am not aware of?

Best,
Fabian

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[nirav-gajera]

@fabianvallon-db
Not a bug — this is expected OCI distribution behavior, and GHCR does support anonymous access for public packages, but it needs the token-exchange step first rather than a PAT sent straight as Authorization: Bearer.

Every /v2/... endpoint on GHCR (and on most OCI-compliant registries) always answers unauthenticated requests with 401 + a WWW-Authenticate challenge, regardless of whether the package is public. That's by spec — you're expected to follow the challenge, not treat the 401 as a hard "no." If you check the response headers on your original request, you'll see something like:

www-authenticate: Bearer realm="https://ghcr.io/token",service="ghcr.io",scope="repository:renovatebot/renovate:pull"

That tells you where to get a token and what scope to ask for. You then request a short-lived token from that realm URL, and use that token (not your PAT directly) as the bearer for the actual API call:

TOKEN=$(curl -s "https://ghcr.io/token?service=ghcr.io&scope=repository:renovatebot/renovate:pull" | jq -r .token)

curl -H "Authorization: Bearer $TOKEN" \
  https://ghcr.io/v2/renovatebot/renovate/tags/list

Since renovate is public, this works fully anonymously — no GitHub login or PAT needed at all for that first /token request. If your PAT-authenticated attempt failed, it's almost certainly because the PAT was sent directly as the bearer token to /tags/list instead of being used to authenticate against /token first (-u username:$PAT on the token request, if you want an authenticated token instead of an anonymous one).

Worth knowing separately: GHCR doesn't return a token expiry, so don't assume a long-lived token — if you're scripting this, just request a fresh token per session rather than caching it.

[fabianvallon-db]

@nirav-gajera

thanks for your answer. that makes a lot of sense. i was misled by copilot to get a user token, so I was extra confused. especially thanks for taking the time for the step-by-step writeup :)