Repository tag author does not change on update from other author

[websolutions-hamburg]

Description

The author of a tag in the repository detail view does not change, if another author pushes an update for the tag. For example if a new latest tag was pushed.

Steps to reproduce

1. Author 1 pushes an image with the tag latest
2. Author 2 pushes another image with the tag latest

• Expected behavior: The author name will be change.
• Actual behavior: The creating author is displayed all the time.

Portus version: 2.4.3@5a616c0ef860567df5700708256f42505cdb9952

[stale]

Thanks for all your contributions!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[websolutions-hamburg]

This issue still exists!

[stale]

Thanks for all your contributions!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[websolutions-hamburg]

This issue still exists!

[Jean-Baptiste-Lasselle]

hi @websolutions-hamburg I am interested in this issue, have already solved several portus issues, maybe will solve this one as well...
Anyhow, to start with :

• There exists a 2.5 docker image of portus, see Garbage Collector removes all tags #2241 (comment)
• try exact same test you ran, but this time docker image version 2.5 instead of the version you used.
• my guess, (I bet 50% on that one)what the developers did in portus source code, is that :
  • the image tag author is set at tag creation time,
  • when the webhook coming from the registry, to portus is processed, every field in the json object sent by registry, as payload for the webhook, does not contain an author field.
  • And the registry is right about that : there should not be any author field in the webhook payload, identity of the author should be infered by portus, based on the JWT token in the request, authenticating a portus user.
  • So I bet what the developers did is "just takethe payload and save it to database"
  • And I just described the fix without even opening the source code.

Waiting for your results with portus:2.5 docier image

[Jean-Baptiste-Lasselle]

Update : lost my bet, I wrote smthg utterly stupid, and learned more

Ok, so I think I lost my 50cents bet, and I wrote something stupid, so learned a deeper lesson on portus internals :

• No, when the registry send a webhook to portus, it should not use the ID token of the portus user who executed the docker pushcommand :
  • First, because portus doesn't want any user to have access to the notifications endpoint, reserved to registry
  • Second, because portus therefore wants to know it actually is the registry, who is sending the webhook, so the registry must have its own auth token, to authenticate to portus as the registry service sending a notification, not a user playing with his docker client. Or worse.
  • Third, because yes, it makes sense, that the notification webhook payload, the registry tells the portus who has just pushed the image ! Indeed, portus emphasizes so much on the accountability provided by portus, to a docker registry service.
• I'm almost sure I found one field, in the registry's webhook payload json schema, one field that is supposed to let the webhook recipient, who docker pushed. (Or who signed the the pushed image ?) : see the "pusher": "trustedbuilder", field, in the example below (coming from official docker docs, cf. https://docs.docker.com/docker-hub/webhooks/#example-webhook-payload) :

{
  "callback_url": "https://registry.hub.docker.com/u/svendowideit/testhook/hook/2141b5bi5i5b02bec211i4eeih0242eg11000a/",
  "push_data": {
    "images": [
        "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3",
        "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c",
        "..."
    ],
    "pushed_at": 1.417566161e+09,
    "pusher": "trustedbuilder",
    "tag": "latest"
  },
  "repository": {
    "comment_count": 0,
    "date_created": 1.417494799e+09,
    "description": "",
    "dockerfile": "#\n# BUILD\u0009\u0009docker build -t svendowideit/apt-cacher .\n# RUN\u0009\u0009docker run -d -p 3142:3142 -name apt-cacher-run apt-cacher\n#\n# and then you can run containers with:\n# \u0009\u0009docker run -t -i -rm -e http_proxy http://192.168.1.2:3142/ debian bash\n#\nFROM\u0009\u0009ubuntu\n\n\nVOLUME\u0009\u0009[/var/cache/apt-cacher-ng]\nRUN\u0009\u0009apt-get update ; apt-get install -yq apt-cacher-ng\n\nEXPOSE \u0009\u00093142\nCMD\u0009\u0009chmod 777 /var/cache/apt-cacher-ng ; /etc/init.d/apt-cacher-ng start ; tail -f /var/log/apt-cacher-ng/*\n",
    "full_description": "Docker Hub based automated build from a GitHub repo",
    "is_official": false,
    "is_private": true,
    "is_trusted": true,
    "name": "testhook",
    "namespace": "svendowideit",
    "owner": "svendowideit",
    "repo_name": "svendowideit/testhook",
    "repo_url": "https://registry.hub.docker.com/u/svendowideit/testhook/",
    "star_count": 0,
    "status": "Active"
  }
}

Now I will run tests to determine for sure, what is in this pusher field, it won't be hard to check whether the token i used to docker login is the value found in the webhook payload . I will see that setting PORTUS_LOG_LEVEL=debug . I'm almost sure it's gonna be a yes.

Ok, so now I think we have serious data to solve this issue.

[stale]

Thanks for all your contributions!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[websolutions-hamburg]

unstale

[stale]

Thanks for all your contributions!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[websolutions-hamburg]

unstale

[stale]

Thanks for all your contributions!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

Thanks for all your contributions!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.