Hi Ian
On 2025/04/04 11:08, Ian Jackson wrote:
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.
Oh, that sounds like a quick and simple procedural admin task, sure, I'd
be happy to help!
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.
Are the dates / times you describe here accurate? It seems that you are
accusing DSA of ignoring your messages since the beginning of April
2025, which we're 4 days in right now. Even 14th of March was just about
3 weeks ago?
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.
Wait, what? I thought that things were going well and that ftpmaster
supported the project and that things were mostly falling in place?
Which is it? If I were to be delegated to this delegation, I would not
be in favour of going against ftpmaster and I would vote against
overriding them in my capacity in this delegation.
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.
My honest opinion: You need to be more patient and not run to the
biggest hammer you can find when things aren't going as fast as you'd like.
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.
That's a big claim based on what we've seen at least publicly, I hope
ftpmaster is willing to make some statement and affirm their willingness
to help. I have explicitly Cc'd them and hope they do so in a timely
fashion.
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.
I'm sorry Ian, but I couldn't second such a GR. I know you've worked on
this for 6+ years and it's finished baking and ready for prime time, and
that you're frustrated that it's not deployed yet, but I can't second
something that puts more pressure or rush on the ftpmaster team. They
have a (really freaking huge) responsibility to keep uploads /
publishing of packages safe, if anything, I would want them to be as
thoughtful and methodological as humanly possible when it comes to
making changes, and I while I don't expect perfection from anyone, I
would want them at the very least to be somewhat confident of what is
implemented and how it works before it goes live.
Also, we are 11 days away from soft freeze starting, and while the NEW
queue has gotten shorter (which is great), imho that should really get
priority over new implementations so that DDs and other contributors can
get a chance to finish their goals for the Trixie release.
This is just the opinion of one DD, others may feel different, YMMV,
IANAL etc other disclaimers.
-Jonathan
