[FEAT] Allow fine-grained control of packages permission #3577

Needs and benefits

Currently, packages are scoped to user or organization and inherit all permissions and visibility from them. As such, currently:

• All packages within public organization are visible, even if they are attached to private repository
• Every member of organization that is in a team with Write access to Packages unit can overwrite any package in organization, even if said package is attached to repository that they do not have access to.

Feature Description

I propose that we take some liberal inspiration from GitHub implementation of permissions for packages. Specifically, for team permissions (organization-specific) we would do the following:

• Allow organization admins to change visibility of each package, with new packages defaulting to visibility of organization.
• When package is linked to repository, automatically inherit visibility of repository as new default for this package (unless manually changed beforehand as above).
• When package is linked to repository, only allow pushes from organization members within a team that have Write permission to "Packages" unit AND access to linked repository.
• When package is linked to repository which has private visibility, only allow pulls from organization members within a team that have Read permission to "Packages" unit AND access to linked repository.
• Allow teams to be configured on whether their members can push NEW packages to organization. This would work similarly to "Create repositories" option we already have there.

Following should be done on Actions side:

• Allow organization admins/users to configure whether to grant Action tokens permission to push new packages to organization/user that is owner of repository under which Action is running.
• Allow repository admin to configure whether to grant Action token full Write permissions to all packages that are linked to repository under which Action is running, regardless of package visibility configuration.

Screenshots

No response

Seems to be related to #2699, where more discussion has already taken place.

Also see #5388 which was closed

Scoping packages to the organization/user instead of the repository creates a mismatch between visibility and access that most users won’t expect.

In practice, many setups need a mix of public and private projects under the same org. With the current model, packages tied to private repositories can still become visible (or modifiable) based solely on org-level settings. This breaks the assumption that repository boundaries define access and can unintentionally expose internal artifacts or allow changes from users who shouldn’t have them.

From a UX standpoint, this is also non-obvious. Most users will assume packages follow repository visibility and won’t realize they need to manage a separate permission model. That increases the risk of accidental exposure or modification.

Aligning package scope with repositories (or making it explicitly configurable per package) would better match expectations and reduce both security and usability issues.

Im keeping orgs private until I figure out what a good next step is. Either I use a private self-hosted reg or I create a second org. Im not liking either solution right now.

Granular control over package visibility would be a better solution.

@ramones wrote in #3577 (comment):

Granular control over package visibility would be a better solution.

100%

I currently operate with a bit of paranoia because I prefer to have my orgs public. I’ve considered using other registries as well.

For the record, changing the visibility of packages is a feature Forgejo will accept (because there's no written opposition to it). The actions side of things likely needs more discussions as messing around with the permissions like that is a huge security undertaking to do that in safe and expected manner.

CC @ramones

@Gusted what's the best way to discuss this somewhere? I haven't contributed to forgejo before, so I'm a bit out of the loop. Is there a matrix/slack/discord?

@ramones The best place to discuss is in issues because they are asynchronous and allow us to go back to figure out why we ended up with a particular design. Here isn't a bad place. What is needed is a plan. Somebody has to dig into the topic and explore what's going to be impacted, discover potential challenges, and then start in small steps.

#3571 is related. #3571 (comment) shows the current plan regarding packages in the context of Forgejo Actions.

From what I understand from earlier threads (and what i'd prefer), a good first step would be something like:

• packages not linked to repos keep org/user visibility
• packages that are linked to repos will receive their org visibility (afaik only public, internal and private exist)
• reading said package requires read access to unit.TypePackages on the linked repo (afaik this is not a thing yet)
• writing/managing packages requires write access to unit.TypePackages on the linked repo
• admins can always bypass this

I think a first safe change is to make packages follow repo-visibility. package lookup should happen early enough to account for RepoID. probably in services/context/package.go. models/packages/package_version.go also has no visibility filter currently. I can already start on some helper functions to check what permission a package would have.

I guess we should keep in mind that there are going to be repo's affected by this first change.

If I'm not mistaken, a package registry is attached to a user or organization. Packages are merely linked to repositories, not owned by repositories. The only (?) effect this has is that a package appears in the list of packages of a repository. Even when linked, packages are not managed within a repository, but within the package registry (i.e. the user's or organization's scope). Considering that, I find the idea to impose a repository's visibility on a linked package questionable.

It also raises a number of questions:

• How would the permission model look like? For example, what about users that have access to the package registry, but not to that particular repository? Should tokens with write:repository get access to packages?
• Forgejo performs auto-linking of packages based on their name. That's likely lead to permission issues.
• How can existing package registries be upgraded without breaking them?
• Do all package formats support that kind of segregation? For example, Debian generates a central package index. Is that compatible with varying visibility? If not, can it be made compatible? What about the gazillion other formats that Forgejo supports?
• Some package formats require signing. Should repositories with a different visibility reuse the existing signing keys?

That might also be a good idea to investigate alternatives, which might require more work initially, but lead to a more flexible, powerful, and sustainable solution. For example, would it make sense to turn package registries into a repository-like concept? That would mean that a user or organization can have zero or more package registries, all with their own permissions. Or should repositories get a separate package registry that should not be shared with the owner?

In that case maybe linked-repo inheritance is more of a hack than it is an implementation.

Would it make sense to use some form of "registry registry"? where you can setup one public and one private registry, and push packages to either (or have a public, internal, private registry that's a set prefix)? It's kind of similar to creating two orgs, only it's not under one name. This is just an idea to throw around.

I was also thinking about just having a seperate registry on repo-level, but then it's very easy to dupe namespaces, packages etc and the API would become quite messy.

Edit: I just realized that the first idea was exactly what you described, oops.

@ramones wrote in #3577 (comment):

Would it make sense to use some form of "registry registry"? where you can setup one public and one private registry, and push packages to either (or have a public, internal, private registry that's a set prefix)? It's kind of similar to creating two orgs, only it's not under one name. This is just an idea to throw around.

My personal preference would be a model that's similar to Artifactory or Nexus: a user or organization can have as many package registries as they like. Each one has a dedicated name, namespace, permissions, visibility, and tokens. It can host a particular type of packages only, and be optionally declared as a pull-through cache (if we ever introduce that feature). That's the most flexible, powerful, and scalable model with the least number of WTFs. In short, it's like repositories, but for packages.

The question is: Can we get there? And if so, can we do it in a backwards-compatible manner?

As said before, somebody has to research it and come up with a plan. It's always possible to ask for help.