On Friday, June 14, 2024 5:25:33 PM EDT Russ Allbery wrote: > Ansgar π <ans...@43-1.org> writes: > > On Fri, 2024-06-14 at 11:45 -0700, 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. > > > > This would require the check to be implemented correctly in tag2upload. > > Otherwise whatever check dak performs is fairly useless. > > It requires that the signature on the Git tag be correctly checked and > that fingerprint be put into the *.dsc file, yes. > > It doesn't require that dak then also trust the authorization checks.
Yes. It does. Since DAK has no way to check the signature of the tag against the keyring, it has to trust the source package signature done by tag2upload. The only two choices are blindly trust tag2upload is correct or don't accept uploads from tag2upload. > > We would also have a new critical system written and maintained by 1.2 > > people in a fairly old-style Perl dialect that have previously not kept > > up with promises to maintain software stacks (e.g., systemd-shim which > > then had to be replaced by other people with something else). > > Yes, the tag2upload developers implemented the service the way that they > implemented it, and the proposed GR would say that they can deploy that > implementation. Asking them to redo that work in a different programming > language or with a substantially different architecture before it can be > deployed is not, at this point, a reasonable request, even apart from the > general principle that Debian is a volunteer project and no one is > required to do work. > > I think that some of the posts on this thread are exactly backwards in > their understanding of human motivation. Blocking someone's work from > being used until it's done the way that you would have done it yourself is > not motivating, it's horribly demotivating. Seeing your work deployed > live and actively used by Debian does not eliminate the motivation to make > any further changes; rather, it increases the willingness to do further > work drastically. My impression (and I may be wrong, because it was awhile ago and since I'm not an FTP Master I wasn't super focused on it) is that the fundamental issue is tag2upload inherently requiring DAK to blindly accept anything tag2upload signs and the FTP delegates not being comfortable with that. I think that was clearly communicated and they didn't like that answer and here we are. That was the issue last time this was discussed (IIRC) and it doesn't appear that anything has changed. I don't see how it can with the current architecture. I suspect a vote of no confidence by the project in the FTP Masters would not be super motivating either. Scott K
signature.asc
Description: This is a digitally signed message part.
