Re: [RFC] General Resolution to deploy tag2upload
Scott Kitterman <debian@kitterman.com> writes:
> On Friday, June 14, 2024 2:45:55 PM EDT Russ Allbery wrote:
>> Sorry, I don't understand. What isn't complete? I just explained how
>> dak could continue to enforce all the same authorization checks as it
>> does today. This is part of the design as proposed. The key
>> fingerprint of the original tag signer is present in the Git-Tag-Info
>> header in the *.dsc file as uploaded to dak.
> Can, but doesn't currently. Elsewhere it has been claimed that
> tag2upload can be implemented with no changes elsewhere and I think
> that's just not true.
tag2upload performs the same permission checks that dak does, modulo the
emergency edge case that Joerg mentioned as an aside, that I'm not sure
many people previously knew existed, and that Ian is currently chasing
down in a separate bug so that parity of checks can be restored. That's
the sense in which it can be implemented with no changes elsewhere.
If I were maintaining dak, I personally would extract the tag fingerprint
and redo the permission check for tag2upload uploads because I personally
prefer an authorization model where checks all happen in one place, even
if some of them are redundant. But this isn't a technical requirement,
only a robustness property.
In general, there are always going to be new cases that have to be taken
into account. No design can ever anticipate everything. For example, I
don't know how many people knew about the emergency ACL mechanism that
Joerg mentioned before this thread; I certainly didn't, and I don't
believe any of the tag2upload developers did. I'm sure something else
like that will come up after the GR, and we'll handle it like reasonable
adults who are collaborating together on a project.
However, in this case, this concern was anticipated and is already covered
in the tag2upload design as proposed.
> Which means that in the future, the tag2upload developers can make
> whatever changes they want and the FTP team is required to accept them?
One part of the answer to that question is no, the GR specifies a design,
and the FTP team can assume that tag2upload follows that design.
But another part of the answer is that you seem to be anticipating a level
of animosity and bad faith that I find rather disturbing. If, in the
future, the FTP team starts rejecting every package I upload because they
don't like me personally, am I required to accept that because they are
project delegates who have the delegated power to decide what packages may
be uploaded? No, of course not; we have all sorts of informal and formal
mechanisms to handle disputes. But also, no one on the FTP team would
ever do such a thing.
The tag2upload developers have been working on this system for many years
now. Deployment has been blocked by an FTP team decision. At this point,
the tag2upload developers are quite understandably not willing to do more
work unless their work can actually be used by the project. The design
has gone through multiple iterative improvements, and while it can always
be better, at some point we need to make a decision about whether we're
going to ask them to abandon it or let them deploy it. The decision of
the FTP team appears to be that they should abandon it. The tag2upload
developers are proposing to appeal that decision to the project as a
whole.
Deciding to deploy the service does not mean freezing the whole thing
as-is forever. It's inevitable that new issues will arise once the
service is running, and those will need to be addressed. It does mean
extending trust to the tag2upload developers to manage their portion of
the service, similar to how we trust the FTP team to manage dak. That
trust includes expecting them to respond reasonably to concerns and
problems as they arise.
There is no need for this to be personal or hostile. I'm also a project
delegate in another area, and I consider it part of the role of a project
delegate to accept guidance from the project. I will make mistakes. I
will also make decisions that I don't think are mistakes but that don't
match what the project wants. The project gets to decide via GR if I'm
wrong. That's part of the bargain I accepted when I joined the project.
If they so decide, it's my responsibility to go along with that decision
in good faith and with good will, or to decide that I no longer want to do
the delegated work.
The point of the GR is to provide clear guidance from the project: either
deploy this thing so that we can see how it works and further improve it,
or abandon the idea. We need to get some closure on this; talking about
it forever while blocking forward progress creates animosity and
frustration. Once the project provides that closure, I would expect
everyone involved to reorient around the guidance that the project has
provided and work collaboratively together on Debian, just like we all try
to do in every other area.
> I'm still concerned about how this is going to work in practice. the
> tag2upload developers seem to be very confident that they have a good
> design that is ready to be deployed and once the FTP Masters are
> overridden on this, until such time as this natural decay runs, there's
> no incentive for them to cooperate.
There is the same incentive as there is for anyone working on Debian to
cooperate with other people working on Debian: we're all on the same side,
trying to do something hard together, and part of that is remaining open
to good ideas and good-faith criticism from our collaborators.
Working on Debian should not be an exercise in hostile brinkmanship and
rules-lawyering. The point of the GR is to resolve a fundamental point of
disagreement following our documented constitutional process for doing so.
That does not require turning off our brains or abandoning normal
principles of collaborative development.
> Is anyone volunteering to do the DAK changes to use Git-Tag-Info header
> to get the signature if the source package is signed by a tag2upload
> key?
If this is actually the blocker for you in voting for this proposal, point
me at the current dak source repository and I will look at implementing
this. I have not worked on dak before and will have to make some
assumptions (most notably about how dak will be configured with the
tag2upload key fingerprints), so you may need to tweak whatever I come up
with.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: