Hello everyone, I seek seconds for the General Resolution at the end of this e-mail. The preceding sections are an introductory explanation and rationale.
We have reviewed the discussion we've already had and prepared an FAQ, linked below. Thank you for all the input on my previous posting, which has resulted in a number of changes. ===== 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 & easier for us to do most of our uploads - it improves the traceability & auditability of our source-only uploads 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 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. In our design, the git tag contains simple metadata that can be written out by hand. ftpmaster stated a hard requirement that the signed tag must additionally include a manifest of all files in the .dsc. However, due to several factors, such a file manifest cannot be generated without the uploader building a source package. The whole point of tag2upload is to move that process off the uploader's system, and onto controlled project infrastructure. We think that it should be possible to upload packages without any complex Debian-specific tools, and we want to support as many of our existing git workflows as we can. Meeting these goals requires accepting source packages constructed and uploaded by the tag2upload service. ===== CONSERVATISM & TRACEABILITY We are concerned that ftpmaster's position is due more to conservatism, leading to an unwillingness to extend trust beyond our existing processes, no matter how carefully designed and implemented the new processes may be. 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, the tag2upload project will be unstuck, and could be deployed in a matter of months. Then 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. ===== WHAT'S NEXT Initially, we'll complete the implementation and deployment work, in collaboration with DSA. When we're ready, we'll advertise for early adopters, who are happy to put up with teething troubles. Eventually we expect many people to switch to using tag2upload for all their source-only uploads, thanks to its convenience. What comes after that will be up to all of us. We intend tag2upload to be an incremental change, which meets people where they are, and only gives them more options. Debian is big, and different packages and situations call for different solutions. We do not pretend that tag2upload will be capable of handling all of them. But it will indeed handle most of our day-to-day source-only uploads. ===== LINKS https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-FAQ.md -- answers to some Frequently Asked Questions (FAQ) https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Jackson -- recent mini-debconf talk outlining the system https://www.eyrie.org/~eagle/notes/debian/tag2upload.html -- Russ's security review 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 design reviewed by Jonathan McDowell and Russ Allbery, should be deployed to official Debian infrastructure. 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's decision: the Debian Archive should be configured to accept and trust uploads from the tag2upload service. 3. Future changes to tag2upload should follow normal Debian processes. 4. Nothing in this resolution should be taken as requiring maintainers to use any particular git or salsa workflows. END FORMAL RESOLUTION TEXT ===== This resolution requires a simple majority. There is no supermajority requirement for Constitution §4.1(3). -- Sean Whitton
signature.asc
Description: PGP signature
