Permissions for package repositories

[kolaente]

Feature Description

Currently, the new package repository uses the public/private status of the organization/user the package belongs to. This works fine for most use cases until one wants to make one package private and all others not, or vice-versa. It would be nice to have additional control over the visibility of packages.

I see three possible solutions to this:

• Add a simple switch "This package is public", similar to repos and keep the current permission logic. Easy to implement, could be extended with the second solution in the future.
• Couple the package permissions to the repo a package belongs to. If its repo is private, so is the package. This would also allow re-using read/write permissions from the repo and is probably the most intuitive. However, it has two small downsides:
  • Packages without an associated repo would be public - maybe they could just use the current permission model.
  • When publishing a new package from a private repo there would be a brief period where the package is public until the repo is properly associated to it and permissions are used from that. This could be avoided by implementing the first solution first and making new packages private by default.
• Implement a separate, full-blown permission system for packages similiar to what we currently have for repos. Probably requires the most effort and requires duplicating permissions.

Personally, I like the second solution as the most intuitive or the most complete.

Similar to #20093 (comment)

[KN4CK3R]

I will add a reference to this issue in #19270 for the item Fine-granular access model.

[simarmannsingh]

This would be a very nice feature to have if access control can also be applied to gitea packages, say docker images.
Waiting for this to release.

[Emiliaaah]

This is something I'm missing in particular for the container registry. The current way access tokens work is very limiting, I would like to be able to create an access tokens per vm I have running, and then have the option to select which specific organizations they have access to/ are able to pull container images from in my specific use case.

Not having this option would mean I'd have to end up giving all my vm's access to all public and private packages. Now this would be somewhat helped by organization level access tokens (#25900), but in the case of docker where you can only have 1 set of credentials per docker registry this would end up being too limiting. In those cases having more granular control over which org's/ repo's an access token has access would be really great.

[Frankkkkk]

IMHO, the Gitlab way of storing artifacts by linking them to a specific repo is way easier: if a repo is public, then so are the packages. If not then the authz falls back to the repo policy. This makes it easier too when allowing the action runner to publish images/etc. linked to the repo

[KN4CK3R]

Package permissions are only easy to implement if there is no need for a stored index. NuGet, npm and some others use a simple XML, JSON, text list which can be generated on the fly. Other package types indices are heavy to compute. APT, Debian and RPM for example compute signatures for the index. In this case you don't want to generate it on the fly and that somehow prevents package level permissions for these package types.

[bvandevliet]

IMHO, the Gitlab way of storing artifacts by linking them to a specific repo is way easier: if a repo is public, then so are the packages. If not then the authz falls back to the repo policy. This makes it easier too when allowing the action runner to publish images/etc. linked to the repo

Exactly, this makes much more sense than relying on the visibility of the user that publishes a package. The organizational preferences should at al times and in all cases be leading in my opinion.. at a minimum. Then it would be nice if there's an option to "override policies" on a per package basis.