Hello everyone, This is a draft GR. I'm posting it now for textual review, because of the relative shortness of our official discussion periods.
After some time for review, I'll post again seeking seconds. The first sections are an introductory discussion. For the actual GR text, scroll down to the bottom of this e-mail. Thanks. ===== INTRODUCTION The tag2upload system, designed for deployment on official Debian infrastructure, allows DDs and DMs to make source-only uploads simply by pushing a signed git tag. There are two key advantages: - it will be much quicker and easier for us to do most of our uploads - it improves the traceability and auditability of our source-only uploads, in ways that are particular salient in the wake of xz-utils. The system works like this: 1. Maintainer types 'git debpush' to sign and push a suitable git tag. The tag includes certain metadata that makes the maintainer's intention to upload fully traceable, and unambiguous. 2. A robot on DSA infrastructure automatically, reliably and traceably builds the source package, and uploads it to the Debian Archive. tag2upload will be an additional option for your source-only uploads; no-one will be required to use it. For more information on the details of the system itself, I've included some links down below. The design is complete, and a prototype is fully implemented with a thorough test suite. In testing, it has been used to perform real uploads. As tag2upload is security-sensitive, the design has had careful, independent security review from Russ Allbery and Jonathan McDowell, who did not have any part in the original design and implementation. I note that Jonathan is one of the highly trusted maintainers of our keyring of human uploaders. ===== NEED FOR A GR So, why am I proposing a GR? The ftpmaster team have refused to trust uploads coming from the tag2upload service. This GR is to override that decision. ftpmaster stated a hard requirement that dak has to be able to completely re-perform the verification of maintainer intent done by the tag2upload service. That goal cannot be met without fatally undermining the tag2upload design and user experience. Russ Allbery, and others, tried very hard to get ftpmaster to explain why this should be a requirement, but we never got an answer that we could understand as a strong technical objection, despite many attempts. We think that ftpmaster's position lies more in simple conservatism, being in favour of existing processes by default, than it lies in actual technical arguments against tag2upload. While we want people in Debian in critical paths for archive security to be relatively conservative, that conservatism can be taken too far, and we think that is what has happened in this case. In fact, tag2upload significantly *improves* the traceability of our source-only uploads. Currently, source packages are constructed from git with relatively ad-hoc command line invocations, using whatever tooling the maintainer has installed on their laptop. This does not give an adequate level of traceability. tag2upload will be a massive *improvement* to traceability since it will restore the formal and traceable link between what most maintainers actually work with and treat as canonical (git, nowadays), and what Debian as an institution officially publishes (packages). ===== THE DESIGN & IMPLEMENTATION ARE LATE-STAGE We wish to be clear that tag2upload can be deployed without *any* code changes to dak. It just needs to be given a suitably trusted key, very similar to how buildds have trusted keys. There are a few loose ends we want to complete to turn the prototype into the finished service. Some design adjustments made in response to Russ Allbery's security review are still to be implemented, and we will arrange how the deployment will work in consultation with DSA. Should this GR pass, then the tag2upload project will be unstuck, and could be deployed in a matter of months, and the source-only uploads of as many of us who want it can become just 'git debpush' and done, without any other workflow changes or learning. There do not exist any other designs that are anywhere near complete, and there are no other implementations, for upload-by-git-tag. ===== LINKS REGARDING THE DESIGN https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Jackson -- recent mini-debconf talk outlining the system https://salsa.debian.org/dgit-team/dgit/-/blob/master/git-debpush.1.pod -- the tool maintainers will use https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-DESIGN.txt -- the design & deployment of the service https://salsa.debian.org/dgit-team/dgit/-/blob/master/tag2upload.5.pod -- the syntax & semantics of the tags git-debpush makes The design is not expected to change significantly, but we may tweak details in response to feedback from d-vote, and while finishing the server-side deployment implementation, in consultation with DSA. ===== BEGIN FORMAL RESOLUTION TEXT tag2upload allows DDs and DMs to upload simply by using the git-debpush(1) script to push a signed git tag. 1. tag2upload, in the form designed and implemented by Sean Whitton and Ian Jackson, and reviewed by Jonathan McDowell and Russ Allbery, should be deployed to official Debian infrastructure. 2. Under Constitution §4.1(3), we overrule the ftpmaster delegation's decision: The Debian archive should be configured to accept and trust uploads from the tag2upload service. 3. Nothing in this resolution should be taken as requiring maintainers to use any particular git or salsa workflows. END FORMAL RESOLUTION TEXT ===== This resolution will require a simple majority. There is no supermajority requirement for Constitution §4.1(3). -- Sean Whitton
