Issue with Public Package Access After Updating to Gitea 1.24.x

Install/Maintain/Configure
1

Hi everyone,

I recently updated my self‑hosted Gitea instance from v1.23.8 → v1.24.2, and since the upgrade I’ve run into a strange issue with Python package downloads that worked perfectly before the update.

Problem

  • The organization and repository are both set to public.

  • When I upload a Python package (via built‑in package registry), it used to be downloadable publicly no login required.

  • After the update, trying to access the public package link returns:

    404 Page Not Found

  • However, when I’m logged in, I can view and download the package without any errors.

What I Found

  • Public access only works when packages are uploaded to a user account.

  • If I upload the same package under an organization, downloads fail with a 404 unless I’m logged in.

So at the moment:

:check_mark: Packages in user repos → publicly accessible

Packages in organization repos → 404 unless authenticated

Has Anyone Seen This?

I haven’t been able to find a configuration setting that would block public access for org packages, and the repo visibility is definitely public.

Some questions I have:

  • Is this a known behavior/bug in Gitea 1.24.x related to the package registry?

  • Are there permission settings I’m missing that control public downloads for org‑hosted packages?

  • Any ideas on how to restore the previous behavior so public users (unauthenticated) can download packages hosted in an org repo?

Environment

  • Gitea v1.24.2

  • Python packages via built‑in registry

  • PostgreSQL backend

  • HTTPS reverse proxy in front

Thanks in advance for any insights and please let me know if you need logs or sample URLs to troubleshoot further!

Cheers!

2

I’m a bit confused by your use-case.

Git, whether it’s Gitea or Github etc., is a distributed version control system for collaboration in the development of source code, documentation etc. A package management system as (say) part of the Python environment, however, is local to the developer. I might be collaborating with a someone who has her Python environment setup differently from mine. That’s her choice, she might be working on projects that require different packages (although these should strictly be completely independent). TOML files list the dependencies your development requires and indirectly tell your colleague’s Python environment what packages it needs. (But the UUIDs can occasionally be corrupted if they are overwritten by a merge for instance.) When a TOML file specifies a dependency that your collaborator hasn’t got, that person’s local Python environment should pull the correct package and its dependencies (if any).

If, on the other hand, you want to develop a single “app”, whether it uses postgresql or whatever, and you want it to run out-of-the-box, you might want to consider a container (e.g. Docker), that way the whole thing “just works” for the user, with no mucking about with TOML files etc.

So I don’t know whether you are using Gitea for collaborative development or not.

Also, to be picky, it might save confusion, at least to me, if you didn’t use terms like “upload” and “download” in the context of git. Stick to git vocabulary for git operations.

Are you trying to execute (i.e. run) your Python package on your Gitea server hardware? Or is this about code coverage, git runners etc.?