Permissions for package repositories #9311

New Issue

GiteaMirror · 2025-11-02T08:34:53-06:00

GiteaMirror commented

2025-11-02 08:34:53 -06:00

Originally created by @kolaente on GitHub (Aug 1, 2022).

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 https://github.com/go-gitea/gitea/issues/20093#issuecomment-1200996879

Originally created by @kolaente on GitHub (Aug 1, 2022). ### 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 https://github.com/go-gitea/gitea/issues/20093#issuecomment-1200996879

GiteaMirror added the topic/packages type/proposal type/feature labels 2025-11-02 08:34:53 -06:00

GiteaMirror commented

2025-11-02 08:34:53 -06:00

@KN4CK3R commented on GitHub (Aug 3, 2022):

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

@KN4CK3R commented on GitHub (Aug 3, 2022): I will add a reference to this issue in #19270 for the item `Fine-granular access model`.

GiteaMirror commented

2025-11-02 08:34:54 -06:00

@simarmannsingh commented on GitHub (Mar 24, 2024):

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.

@simarmannsingh commented on GitHub (Mar 24, 2024): 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.

GiteaMirror commented

2025-11-02 08:34:54 -06:00

@Emiliaaah commented on GitHub (Apr 6, 2024):

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.

@Emiliaaah commented on GitHub (Apr 6, 2024): 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.

GiteaMirror commented

2025-11-02 08:34:54 -06:00

@Frankkkkk commented on GitHub (Apr 21, 2024):

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

@Frankkkkk commented on GitHub (Apr 21, 2024): 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

GiteaMirror commented

2025-11-02 08:34:54 -06:00

@KN4CK3R commented on GitHub (Apr 22, 2024):

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.

@KN4CK3R commented on GitHub (Apr 22, 2024): 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.

GiteaMirror commented

2025-11-02 08:34:55 -06:00

@bvandevliet commented on GitHub (Jan 8, 2025):

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.

@bvandevliet commented on GitHub (Jan 8, 2025): > 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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9311