Several years ago, several people proposed a mechanism to upload packages to Debian just by doing "git tag" and "git push".
Two not too long discussions on
debian-devel (first and second) did not end with an agreement how this mechanism could work.1
The central problem was the ability to properly trace uploads back to the ones who authorised it.
Now, several years later and after re-reading those e-mail threads, I again was stopped at the question: can we do this? Yes, it would not be just "git tag", but could we do with close enough? I have some rudimentary code ready to actually do uploads from the CI. However the list of caveats are currently pretty long.
Yes, it works in principle. It is still disabled here, because in practice it does not yet work.
So what are the problems?
It requires the git tags to include the both signed files for a successful source upload.
This is solved by a new tool that could be a git sub-command.
It just creates the source package, signs it and adds the signed file describing the upload (the
.changes file) to the tag to be pushed.
The CI then extracts the signed files from the tag message and does it's work as normal.
It requires a sufficiently reproducible build for source packages.
Right now it is only known to work with the special
3.0 (gitarchive) source format, but even that requires the latest version of this format.
No idea if it is possible to use others, like
3.0 (quilt) for this purpose.
The shared GitLab runner provides by Salsa do not allow ftp access to the outside. But Debian still uses ftp to do uploads. At least if you don't want to share your ssh key, which can't be restricted to uploads only, but ssh would not work either. And as the current host for those builds, the Google Cloud Platform, does not provide connection tracking support for ftp, there is no easy way to allow that without just allowing everything. So we have no way to currently actually perform uploads from this platform.
As this is code running in a CI under the control of the developer, we can easily do other workflows. Some teams do workflows that do tags after acceptance into the Debian archive. Or they don't use tags at all. With some other markers, like variables or branch names, this support can be expanded easily.
Unrelated to this task here, we might want to think about tying the
.changes files for uploads to the target archive.
As this code makes all of them readily available in form of tag message, replaying them into possible other archives might be more of a concern now.
So to come back to the question, yes we can. We can prepare uploads using our CI in a way that they would be accepted into the Debian archive. It just needs some more work on infrastructure.
Here I have to admit that, after reading it again, I'm not really proud of my own behaviour and have to apologise. ↩