Hi, Andreas. It appears that you forgot to forward your message to
debian-vote. I'm doing that now.
Nothing here is or needs to be secret. So we should be doing all this
in public. Given the history here, transparency is vital.
Sean is responding substantively, and I have strongly encouraged him
to CC -vote too.
Ian.
--- Begin Message ---
Hi again,
As far as I understood (while I was on VAC last weekend), Philipp Kern
used his DSA hat to do the work needed to move tag2upload forward. This
was confirmed by Ansgar:
Am Sat, May 10, 2025 at 12:06:14PM +0200 schrieb Ansgar 🙀:
> Philipp Kern thankfully set up the keyring distribution. So the branch
> could be merged now without breaking the running setup.
>
> The keyring is also configured and uploads might work, except for bugs:
> I wrote an integration test, but it uses a manually crafted package
> which might be slightly wrong.
Given this update, I have a few questions for the teams involved:
1. Is a new delegation still needed, or can tests begin without further
formal steps? If the keyring was installed by DSA as part of their
normal responsibilities, the originally proposed delegation might no
longer be necessary--can someone confirm this?
2. To Ansgar: You had proposed changes to the tag2upload delegation text
Message-ID: <8bfd63ab06da0a549574923b18c98d66da7f05e2.ca...@debian.org>.
Given recent developments, do you think this still needs discussion,
or has your concern been addressed?
3. On team collaboration: It's become quite clear that communication
between the delegated teams (FTP Archives and tag2upload) has been
difficult. I consider this a serious issue. We won't fix a social
problem by reshuffling delegations alone.
Since the draft delegation text mentioned Daniel Gröber, I want to
express thanks for volunteering. Daniel, if you're still willing, I'd
appreciate your view on whether mediation between the teams would be
possible--and in what context or team structure you think that could
work best.
Thanks again to everyone who has pushed this forward despite the
challenges. I hope we're now close to testing a working setup--please
let me know if that's not the case.
Kind regards,
Andreas
Am Fri, May 09, 2025 at 10:38:16PM +0200 schrieb Andreas Tille:
> [public list removed from CC]
>
> Hi Ian,
>
> Just to keep you in the loop: while I haven’t formally announced a VAC
> on debian-private, I’m effectively offline until Monday.
>
> I’ve sent a brief note to the ftpmaster team list to ask them to share
> any concerns or reasons they might have regarding your delegation
> request before then.
>
> I’ll revisit the matter once I’m back online.
>
> Thank you for your patience
> Andreas.
>
> Am Fri, May 09, 2025 at 11:43:22AM +0100 schrieb Ian Jackson:
> > tl;dr:
> >
> > Dear Andreas:
> >
> > Would you please make a temporary delegation, to enable tag2upload ?
> > We think this consists mostly of deploying a 3-line patch to dak.
> >
> >
> > Discussion
> > ----------
> >
> > It is now 7 weeks since we asked the FTP Team to install the
> > tag2upload oracle service's public key on fasolo.
> >
> > During this time the FTP Team have not communicated with us on a
> > technical level at all. They have not asked for test data. They hvve
> > not asked any technical questions. They have not engaged in the
> > discussions on how the Oracle's public key should be conveyed to dak
> > on fasolo.
> >
> > Only after we proposed a draft General Resolution here on -vote, did
> > the FTP Team finally start the implementation work they say they want,
> > and which they could have begun a year ago.
> >
> > That work is still not complete and the FTP Team have refused to give
> > any indication how long they think it will take. They did previously
> > promise a date, but that date (31st March) is long past. Indeed, the
> > FTP Team hardly answer our emails at all.
> >
> > The delay, and the lack of communication, are intolerable.
> >
> > Furthermore even if the FTP Team complete their extra programming
> > work, we naturally expect that there will be teething problems and
> > snags to work out.
> >
> > But the FTP Team won't communicate with us on a technical level, and
> > only reply to emails if vigorously poked here - often not even then.
> > It doesn't seem like they really want to see tag2upload deployed,
> > despite notionally saying they support it. We don't expect that snags
> > and bugs will be resolved in a reasonable timescale, or at all.
> >
> > For these two reasons, we conclude it is necessary to give someone
> > else the authority to install the key, so tag2upload can go live.
> >
> > We therefore hereby formally request that the Debian Project Leader
> > intervenes, by making a temporary delegation.
> >
> >
> > Draft Delegation
> > ----------------
> >
> > We believe we have one volunteer already - Daniel Gröber. It would be
> > much better if this task wasn't done by Sean or me. Daniel: thanks,
> > and are you still up for this ?
> >
> > Does anyone else want to volunteer ? You may be able to base your
> > work on this 3-line patch to dak:
> > https://salsa.debian.org/iwj/dak/-/commits/t2u-minimal
> >
> > We suggest a delegation text like this:
> >
> > Per Debian Constitution 5.1, I hereby delegate the
> > tag2upload Key Installation Task
> > to the following Task Delegates:
> >
> > - Name
> > - Name
> >
> > Task description
> > ----------------
> >
> > 1. Install the tag2upload package signing key on fasolo.
> > (i) in such a way that dak will treat it identically
> > to a key belonging to a normal uploading DD;
> > (ii) or some other similar authority or abilities as
> > is consistent with the tag2upload service's needs,
> > and seems convenient to the Task Delegates;
> > (iii) keeping all changes as minimal as possible.
> >
> > 2. Collaborate with the tag2upload Delegates.
> >
> > 3. Collaborate with the FTP Master Delegates, if they express
> > an interest, but without introducing any significant delay.
> > Final decisions lie with the Task Delegates.
> >
> > 4. Confirm with the tag2upload Delegates that things are working.
> > Resolve any problems (with the key, or with other aspects of dak).
> >
> > 5. Document what was done by email to the FTP Master Delegates,
> > and/or in git, as the Task Delegates consider reasonable.
> >
> > 6. When completed, or if significant obstacles are encountered,
> > report to the debian-project mailing list.
> >
> > The Task Delegates should be granted by DSA whatever permissions are
> > necessary to accomplish the task.
> >
> > This is a new delegation. It is limited to the duration of the
> > task, or until withdrawn by present or future Project Leaders.
> >
> >
> > Thanks,
> > Ian.
> >
> >
> > Appendices
> > ==========
> >
> > Q&A
> > ---
> >
> > Q. We should give the FTP Team more time / you are pushing too hard.
> >
> > A. We have been extraordinarily patient.
> >
> > This project has already been delayed by the FTP Team for half a
> > decade. Progress has only occurred when it looked like the FTP
> > Team might be overruled.
> >
> > See the detailed timeline below.
> >
> >
> > Q. We should wait unti after the release, so as not to disrupt it.
> >
> > A. Release activities are independent of these changes to dak. Indeed
> > the FTP Team have been carrying out unrelated overhaul and QA work
> > on dak during this time.
> >
> >
> > Q. The FTP Team should be allowed to focus on processing NEW.
> >
> > A. Only one FTP Team member ever processes NEW. That FTP Team member
> > is a hero, and is not involved in this disupute. Their work is
> > appreciated, and will not be interrupted.
> >
> > The FTP Team member who is most strongly opposed to tag2upload, is
> > also the one who is tasked with the additional programming work
> > they say they want - and that team member has been participating
> > vigorously in the AI policy thread here on -vote.
> >
> >
> > Q. Wnat is a Temporary Delegation?
> >
> > A. We are all used to delegations as ongoing and not time-limited, but
> > this is not their only purpose in our Constitution.
> >
> > Just as an NMU is how we fix RC bugs or implement TC decisions when
> > the maintainer won't do it, time-limited delegations are the
> > equivalent mechanism the Constitution provides for similar
> > situations outside of the archive itself.
> >
> > In this case what's needed is a simple change to dak.
> >
> >
> > Q. Didn't you come to a compromise agreement with ftpmaster last year?
> >
> > A. We did. It was explicitly signed off by both sides, here:
> >
> > https://browse.dgit.debian.org/dgit.git/commit/?id=e5512e874ddd755e2168b34d1b95f5f3ee487e71
> > https://lists.debian.org/debian-vote/2024/07/msg00024.html
> >
> > That agreement involved us doing substantial additional work to
> > support additional checks by dak (that no other core team thought
> > worthwhile). It also envisaged ftpmaster making changes to dak, to
> > perform those additional checks.
> >
> > We implemented our part. The FTP Team are dragging their heels on
> > their part. We should deploy tag2upload immediately, without those
> > extra parts. No other team in Debian thinks they're ncessary.
> >
> > If the FTP Team still thinks they are necessary after tag2upload is
> > actually deployed, then they can do the necessary work on their own
> > time, later.
> >
> >
> > Recap for those who may not have been following things
> > ------------------------------------------------------
> >
> > tag2upload is a system for allowing every DD and DM to upload simply
> > by signing a git tag. It's had a thorough independent security review
> > by Russ Allbery. It has been blocked for 5 years by the FTP Team.
> >
> > 6 years ago
> >
> > Prototype of tag2upload was demonstrated live in Curitiba,
> > We discussed tag2upload on debian-devel. The proposal was
> > unambiguousloy rejected by the FTP Team.
> >
> > We spent the next few years trying to go via various DPLs
> > and other project grandees.
> >
> > ~1 year ago:
> >
> > We sent a draft GR to -vote, suggesting overruling the FTP Team.
> >
> > ~11 months ago:
> >
> > Only after our GR is formally proposed and seconded, the FTP Team
> > eventually offer a compromise, which we accept.
> >
> > The FTP Team could have started their implementation work.
> >
> > ~4 months ago:
> >
> > Our Delegation was instituted by the DPL (after consultation with
> > the FTP Team and others, of course).
> >
> > 7 weeks ago
> >
> > We generated our production key and we asked for it to be installed.
> >
> > We discovered that the FTP Team had done none of their
> > implementation work. They initially replied abusively, and with a
> > flat "no".
> >
> > At this point tag2upload could have been operational right away
> > without their extra work, with something this three line patch:
> > https://salsa.debian.org/iwj/dak/-/commits/t2u-minimal
> >
> > Eventually the FTP Team gave us a date by which the key would be
> > installed.
> >
> > 5 weeks ago
> >
> > The completion date promised by FTP Team passes without them having
> > written a single line of code.
> >
> > We once again post a draft GR. After a bit of debate, they start on
> > the implementation work for their extra checks.
> >
> > 1.5 weeks ago:
> >
> > Last we heard from the FTP team, here on -vote. Interpreted
> > charitably, that was a holding reply.
> >
> > Our pings have gone unanswered.
> > We have still heard absolutely nothing on a technical level.
> >
> >
> > --
> > Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
> >
> > Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
> > that is a private address which bypasses my fierce spamfilter.
> >
>
> --
> https://fam-tille.de
>
--
https://fam-tille.de
--- End Message ---
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
