Hi, On Fri, 2024-06-14 at 11:45 -0700, Russ Allbery wrote: > Scott Kitterman <deb...@kitterman.com> writes: > > On June 13, 2024 3:29:21 PM UTC, Russ Allbery <r...@debian.org> wrote: > > > > I don't understand why this would be a blocker given that dak can redo > > > the authorization check at the same point that it does authorization > > > checks now, should it so desire.ย This does require a small change to > > > dak to retrieve the key fingerprint from the source package in the case > > > where the source package is signed with the tag2upload key, but that > > > doesn't seem too difficult. > > > I think that if the proposers want to direct use of a specific design > > via GR, it ought to be complete. > > 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. The design says "blindly trust whatever tag2upload might believe" which I don't think is nice given what it believes. Sadly tag2upload upsteam is uncompromising to suggestions to change this, hence this GR proposal. (And given upstream's hard policy to not merge changes not signing off extra legal stuff, I sadly cannot give a more detailed bug report as any fix created as a derived work from that would be unmergable unless there was a Debian fork of the project with a different policy.) 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). Ansgar
