[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

General Resolution to deploy tag2upload



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

Attachment: signature.asc
Description: PGP signature


Reply to: