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

[RFC] General Resolution to deploy tag2upload



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


Reply to: