Container registry cannot be set to private

[unixbird]

Description

Found that there isn't a way to make a container image private meaning anyone can pull the image even if the image is part of a private repo.

Gitea Version

1.19.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

I deploy gitea using kubernetes with kubectl and kubeadm.

Database

None

[KN4CK3R]

Package visibility is the same as owner visibility. If the user or organization is private, the packages are private too. A linked repository does not change the visibility but that may change in future.

[TheDevMinerTV]

It would be cool to have it like GHCR's "every container has it's own visibility setting".

[facorazza]

Personally, I'd like to change the visibility of packages from the linked repository

[bbenouarets]

I would also like it if you could control visibility via the containers or the repository.

[lunny]

For a private orgniazation/user, all the containers of it will be private. For all the public orgniazation/user, all the containers of it will be public.
So I think the requirement here is private containers on public orgniazation/user. Maybe you can change the title to that.

[lippoliv]

I discovered it today, while migrating from GitLab. I was scared. I think this can be improved, while keeping in mind how Gitea deals with repos:

• A repo belongs to a owner
• A repo has a visibility (which differs to the owner)

I think it would be cool if packages (all package types, not just containers) follow the same principle. They can have the owners visbility by default, but users should be able to overwrite it.

(for me my migration now will get hard, probably I temporarily need to put all owners to private visibility)

[lippoliv]

Another use-case (more serious):

1. Org is private
2. Repo is private
3. Some extern user is member of Repo, but NOT on the ORG
4. Now there's a new package, but he cannot download (404)

[bmbkr]

Personally, I'd like to change the visibility of packages from the linked repository

This way makes the most sense to me. It differs the least from the current behavior of mirroring visibility of the user's profile.

[syed-2969]

Hey guys, Can someone please help me to understand how can setup docker container registry in gitea ? I have installed gitea but in packages & registry I didn't find the container registry. Please can someone help me with guiding / pointing to right documentation ?

[frenchcharly]

Hello there,

I think I'm in the correct issue:

1. Have Gitea setup.
2. Have a private Organization
3. Have 2 private repositories owned by said Organization
4. Have a docker image pushed and available under the Packages tab for each of those repositories.
5. Each Package was setup using "Link this package to a repository" in its settings page.
6. User account is owner of the Organization & Repositories

Gitlab CI/CD can push to GItea, no worries, so can I, manually, when building from multiple machines (linux/macOS).

Now, the rub : in any production / staging / dev environment i have, after a successful login to Gitea via docker login, I always get Error response from daemon: unauthorised: reqPackageAccess when trying to pull the image.

In order for me to be able to pull the image, the only solution i have is to set the Organization to public.

Can provide more details if needed but pretty sure that's not expected behaviour from a "private" registry.

[KN4CK3R]

Thank you for the steps. I will have a look later 👍

[KN4CK3R]

@frenchcharly I can't reproduce the behaviour.

Have a docker image pushed and available under the Packages tab for each of those repositories.

You uploaded two images and linked image 1 to repo 1 and image 2 to repo 2?

I created a private org and two private repositories in that org. I pushed an image to the org and linked it to repo 1 (linking a package does not change the permissions at the moment, so this should not change anything). Then I created a new team with view rights and added a second user to this team. This user can now pull the image without problems.

If the pull-user is not in the team I get the expected error
Error response from daemon: failed to resolve reference "...": unexpected status from HEAD request to ...: 401 Unauthorized
Adding the user again, the pull works.

[frenchcharly]

This user can now pull the image without problems.
If the pull-user is not in the team I get the expected error Error response from daemon: failed to resolve reference "...": unexpected status from HEAD request to ...: 401 Unauthorized Adding the user again, the pull works.

Push/pull : encountered no problems whatsoever.
My issue is that the images are accessible via Gitea GUI to any anonymous user.
I had to switch to using Harbor because I couldn't make the images truly private, and that is not optional in my use case.

[KN4CK3R]

What's the url which makes the packages visible? If the owner is not public, every url should result in a 404 error.

[frenchcharly]

What's the url which makes the packages visible? If the owner is not public, every url should result in a 404 error.

As I stated, I had to switch to Harbor because publicly accessible images were a non-starter in my use case. I could try to spin a vm from a backup I have to get you that information, but all I did was explore the Gitea instance in a private browser session and I could access and download the images. Including supposedly private images.

[mcrapts]

@KN4CK3R This is true, but sometimes the owner is public but repositories are not. Images linked to a private repository will still show up in the public user page. I agree with @frenchcharly this is unacceptable and makes the container registry unusable for me.

[edantes-1845]

Hi, everyone.
I have the same behavior with 1.22.1 version. Any Member of organization (with NO ACCESS to packages) can pull packages from this organization. Is it correct behavior?

[lunny]

Hi, everyone. I have the same behavior with 1.22.1 version. Any Member of organization (with NO ACCESS to packages) can pull packages from this organization. Is it correct behavior?

It depends on org is public, limited or private.

[bvandevliet]

This issue seems related: #20596