Developer Role unable to retag images via UI

[fletch3555]

If you are reporting a problem, please make sure the following information are provided:

Expected behavior and actual behavior:
We have users with the Developer role.

Working within the Harbor UI, they are able to manually assign new tags to images, however, they are unable to assign existing tags to images.

To clarify, if a separate image hash is already tagged "abcd", they will be unable to "Add Tag" with the name "abcd".

Doing this through the docker CLI works correctly (and assuming your docker CLI is authenticated to Harbor with a user assigned the "Developer" role)

# Setup
docker pull busybox:1.36
docker tag busybox:1.36 harbor.example.com/myproject/busybox:1.36
docker push harbor.example.com/myproject/busybox:1.36
docker pull busybox:1.37
docker tag busybox:1.37 harbor.example.com/myproject/busybox:1.37
docker push harbor.example.com/myproject/busybox:1.37

# Apply custom tag to 1.36
docker tag harbor.example.com/myproject/busybox:1.36 harbor.example.com/myproject/busybox:abcd
docker push harbor.example.com/myproject/busybox:abcd
# The Harbor UI now shows 2 images, with one tagged 1.36 and abcd and the other tagged 1.37

# Retag "abcd" to 1.37
docker tag harbor.example.com/myproject/busybox:1.37 harbor.example.com/myproject/busybox:abcd
docker push harbor.example.com/myproject/busybox:abcd
# The Harbor UI still shows 2 images, with one tagged 1.36 and the other tagged 1.37 and abcd

Steps to reproduce the problem:

1. Open project in Harbor UI containing 2 images, one with existing tag, and one you want to tag. For example:
   
2. Click on image hash that you want to tag (sha256:4c3d11be in above screenshot)
3. Click "Add Tag" button, type existing image name into "Name" field, then click "OK" button
   
4. Observe error:
   

Versions:
Please specify the versions of following systems.

• harbor version: v2.10.0-6abb4eab (we're currently planning the upgrade to v2.11, but haven't been able to complete it yet)
• docker engine version: 24.0.2
• docker-compose version: 2.18.1

Additional context:

• Harbor config files: N/A
• Log files: N/A

(I don't believe these are relevant to my report, but I can provide them if requested)

[fletch3555]

I just found this issue #20382, which appears to be the same issue, just via API rather than the web UI. Appears there are others with similar complaints.

For what it's worth, the retag permission is granted to all users in the Guest role or higher (including Developer) according to the docs, so I would expect it to work via the UI (and API) as well. Developer role does not have access to delete tags, so doing it as a 2-step process is not possible. I don't think granting everyone Maintainer or Admin access is a valid path forward, nor is it clear in the docs that this would even resolve this use-case.

If desired, we could add a warning prompt about the tag already existing. At the very least, the docs should be updated to clarify this access is only granted via Docker CLI. Though again, I believe this should be allowed within the Harbor API/UI.

[wy65701436]

In the OCI world, the combination of the repository and tag serves as the unique identifier.

Based on your description, the error you encountered in step 4 is the expected behavior. The tag abcd was added to the artifact with digest bc04, so you cannot assign the same tag to another artifact unless you first remove the abcd tag from the artifact with digest bc04.

You can achieve this using the Docker CLI, as it facilitates the removal and reassignment of tags from one artifact to another in the backend.

From my understanding, you would like to see a button that allows for the migration of a tag from one artifact to another.

[reasonerjt]

Current semantic of the API is to "add tag" to an artifact, Harbor has a check to make sure the tag is not added to another artifact.

It would be a break change of API if we remove this check and IMO it's not a high priority. It may be handy for some user but problematic for others.

[fletch3555]

Current semantic of the API is to "add tag" to an artifact, Harbor has a check to make sure the tag is not added to another artifact.

It would be a break change of API if we remove this check and IMO it's not a high priority. It may be handy for some user but problematic for others.

I wouldn't expect the tag to be blindly replaced, but a warning prompt (and possibly an override option for the appropriate access level) seems perfectly reasonable to me. It doesn't necessarily need to be an API change because the web app could simply fire off two API calls (one remove, one add).

I envision this as a simple check for the returned "tag already exists" error, and if the user has correct access, a modal prompt for "do you want to retag to artifact ?". If yes, then fire off a delete of the existing tag then another add tag call which should succeed now. The only problem is that Developers can't delete tags, so a separate "retag" API is likely the better path forward. Adding new API endpoints should never be a breaking change IMO.

At the bare minimum, the docs should be updated to indicate the "retag" action is only doable via docker CLI, because the Developer role does not have access to delete tags and therefore cannot do the manual 2-step process via Harbor UI or API.