Hi everyone.
tl;dr
We need to make an exceptional, short term delegation authorising
the installation of tag2upload's signing key on ftp-master.
We need two volunteers to take on this responsibility; please
volunteer in response to this message if you can do it.
INTRODUCTION
Thanks to a lot of help from DSA, tag2upload is deployed, all
according to spec! We are very excited about this.
However, we can't start our closed beta because the ftpmaster team will
not authorise tag2upload's signing key to upload packages.
We asked them to install the key on 2025-03-14. After some
resistance, they told us they could make their changes and install the
key by the end of March. We've offered technical information, and
asked how it's been going, and in particular when April arrived we
asked about agreeing a new timeline. However, they have been ignoring
our messages for weeks, and there has been no update, and no sign of
any activity.
The tag2upload developers have a DPL delegation which explicitly
grants us a signing key with certain upload privileges. Therefore,
the ftpmaster team does not have any authority to block us, in just
the same way that they can't tell the Release Team that they can't
make a point release. It's just not for them to say.
They could, of course, refuse to offer the Release Team any assistance
in making a point release actually happen. This is Constitution
2.1(1), the volunteer principle.
ftpmaster don't want to see tag2upload in use, and so they are
choosing not to respond to our requests to install the key.
Therefore, we need to temporarily delegate someone else to do it.
TEMPORARILY DELEGATE?
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.
WHAT ABOUT THE DPL?
The DPL has been CC'd on all of the private messages between the
tag2upload developers and the FTP team. We have seen *no response
whatsoever* from him.
Given this, and other interactions we have had or are aware of, we do
not have confidence in the DPL's willingness to take the necessary
action.
THE 2024 AGREEMENT WITH FTPMASTER
Q. Didn't you come to an agreement with ftpmaster last year?
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 have spent the past eight months implementing our side of the
arrangement. They have done nothing, and are still doing nothing.
In other words, they are in breach of our agreement.
FTPMASTER'S POSITION
We don't know what ftpmaster think should happen next since they
haven't said. There is no indication that ftpmaster will start the
implementation work, nor that they are prepared to proceed without it.
They are stonewalling us.
DRAFT GENERAL RESOLUTION
Once we have some volunteers:
We exercise the power of the DPL (via Debian constitution 4.1(3)),
to make a Delegation (8.2). We 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.
REJECTED ALTERNATIVE - ADDING THE KEY TO THE DD KEYRING
One approach that would let tag2upload function correctly, would be
adding the tag2upload service key to debian-keyring.gpg, as if it were
a human uploading DD.
This is an alternative way to work around ftpmaster's unwillingness.
One of them even mentioned it in one message, though it wasn't clear
how serious they were.
But this is a really unpleasant workaround. We would need to audit
elections to check that the tag2upload key hadn't "voted". We would
need to remember to subtract one every time we were calculating
quorum. The keyring maintainers don't like the idea, and we don't
either.
Better is to have dak accept two keyrings with identical authority:
debian-keyring.gpg, and a service keyring debian-tag2upload.gpg
containing the tag2upload key. This seems to us like it would be easy
(and lowest risk, given that this task may be performed by someone
with limited knowledge of the codebase). So that is what we propose.
Q. LET'S JUST GIVE FTPMASTER SOME MORE TIME
ftpmaster have already had 8 months since our agreement last year, and
did nothing during that time. When their inaction became the final
blocker, they initially refused, then pleaded for more time (which we
accepted), then missed their own deadline, then went back to
stonewalling when we asked for a new timeline.
We do not expect that any new deadline would be met. Setting a new
deadline would simply delay matters, and then leave us back where we
started. More generally, it is not the tag2upload developers' job to
project-manage ftpmaster's implementation work.
Ian
for the tag2upload Delegates
--
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.
