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.
[I don't need CC'ing on replies that go to -vote]
Hi,
Ian Jackson <[email protected]> writes:
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.
FWIW, I think this is a reasonable request, and it's long past time tag2upload got unblocked. A delegation by the DPL to get this done feels
like the right organisational tool for the job.
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 ?
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.
On 09/05/25 4:13 pm, Ian Jackson wrote:
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.
Thank you for all the work you (and Sean) have done for tag2upload. I too, agree
that this is the right thing to do here.
I know +1 chains are useless, and I try to avoid them. However, I wanted to express
that I'd have felt very helpless had I been in the same situation as you, provided I
spent an equivalent amount of hours working on tag2upload.
On 2025-05-12 15:33, Sean Whitton wrote:
On Mon 12 May 2025 at 03:16pm +02, Andreas Tille wrote:
Given this update, I have a few questions for the teams involved:All that has happened is that a copy of the public key is now present on
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?
fasolo. dak still does not trust the key.
Therefore the delegation is still required, until and unless the FTP
team merge and deploy their branch.
AIUI the deployment has happened on Saturday. The merge definitely happened[1].
Kind regards
Philipp Kern
[1] https://salsa.debian.org/ftp-team/dak/-/commits/master?ref_type=HEADS
Sean Whitton writes ("Re: tag2upload - request for DPL action"):
We should have been invited to perform testing by the FTP Team.
Indeed, I just tried a test upload of dgit-test-dummy, and it was
REJECT'd with a strange error message.
Should we file a bug against ftp.debian.org? Just write an e-mail?
We have no open channel of communication, despite our best efforts.
For reference, here is the error email. It looks like some part of
the complicated new code failed, but the stderr output doesn't
appeaar in the message, so it's impossible to say what the cause is.
We should have been invited to perform testing by the FTP Team. Indeed,
I just tried a test upload of dgit-test-dummy, and it was REJECT'd with
a strange error message.
Should we file a bug against ftp.debian.org? Just write an e-mail?
We have no open channel of communication, despite our best efforts.
Should we file a bug against ftp.debian.org? Just write an e-mail?
We have no open channel of communication, despite our best efforts.
For reference, here is the error email. It looks like some part of
the complicated new code failed, but the stderr output doesn't
appeaar in the message, so it's impossible to say what the cause is.
That script exists on the ftp-master server, but isn't marked as
executable, which seems a plausible reason for trying to run it via
sudo to be failing.
tag2upload: invalid metadata: Command '['sudo', '-H', '-u', 'dak-unpriv', '/srv/ftp-master.debian.org/dak/scripts/debian/wrap-tag2upload-verify', '--audit', '/dev/stdin']' returned non-zero exit status 1.
Hi, Andreas. It appears that you forgot to forward your message to debian-vote. I'm doing that now.
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.
[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 <[email protected]> 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
This is all very nice, but could you please consider rather
communicating on the BTS rather than use -vote for making progress on
T2A issues?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 163:59:16 |
| Calls: | 12,095 |
| Calls today: | 3 |
| Files: | 15,000 |
| Messages: | 6,517,794 |