Revert auth changes on the Composer registry package endpoint
Context
Composer packages are not files as other package formats. Composer packages are actually simply git tags.
Under this perspective:
- publishing a composer package is actually creating a git tag.
- pulling a composer package is downloading the git tag. Basically, it's download the source code zip archive. We have such button in the GitLab UI. Browse a git tag and you will see in the upper right hand side a button to download the zip file of that tag.
Now, the GitLab Composer Package Registry was implemented to use the Package registry a bit as a cache. It will host those zip files as package files, this way when $ composer
asks for a download url for a package name + version, we can simply point to the package file.
This is ok but how do we create those package files? Well, we created a simple endpoint that users will need to ping to "create" or put the git tag into the package registry.
When that endpoint was implemented we accepted the usual token types: PATs, deploy tokens and CI job tokens. All of them were accepted through the custom http headers.
🎇 The unwanted side impact
In Add ci job token support to the Composer packag... (!127300 - merged), a community effort was made to bring CI job token support to (2.) pulling packages. We spotted a way to do so by accepting ci job tokens sent by basic auth. Meaning that users could use the ci job token to set up the configuration of $ composer
and then simply $ composer update
to pull packages.
The problem is that this MR switched CI job token authentication to basic auth to all endpoints, including the register package endpoint (1.).
That unwanted side effect introduced a breaking change typebug: users with CI jobs publishing composer packages could be executed successfully anymore.
The possible workaround here is to call the register package endpoint using basic auth instead of custom http headers but that is not great because it is still a breaking change.
Thus this MR will revert the auth changes for the ci job token on the register package endpoint to go back to the original behavior. This is issue CI job tokens can't register composer packages (#426617 - closed)
🔬 What does this MR do and why?
- Revert the authentication change on the composer register package endpoint: the ci job token is expected to be passed using custom http headers and not basic auth.
- Update the related specs.
This is a revert of some changes done in !127300 (merged).
🖼 Screenshots or screen recordings
None
🛠 How to set up and validate locally
There is a bit of a setup. Have a GitLab instance running with a runner.
- Create a group and a project in that group.
- In the project, create a
composer.json
file:{ "name": "<group path>/test", "description": "Library XY", "type": "library", "license": "GPL-3.0-only", "authors": [ { "name": "John Doe", "email": "john@example.com" } ], "require": {} }
- Commit the changes.
- Create a tag named
1.2.4
. - Create a
.gitlab-ci.yml
file:image: curlimages/curl register-package: script: - 'curl --header "Job-Token: $CI_JOB_TOKEN" --data tag=1.2.4 "${CI_API_V4_URL}/projects/$CI_PROJECT_ID/packages/composer"'
- Commit the changes and watch the runner execute the job.
On master, the runner will fail to run the $ curl
command.
With this MR, the runner will succeed and you can see the created package in http://gdk.test:8000/<project full path>/-/packages
.
🏁 MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.