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. > It's unclear to me how the FTP Masters could ask for this after the GR, > since the GR takes anything to do with tag2upload out of their hands > going forward. I don't believe this is a correct interpretation of how GRs that override a delegate decision are applied in Debian. For one, absolutely nothing about a GR or any other action in Debian constrains what FTP Masters can *ask* for. Surely that's obvious. It would only constrain what FTP Masters can *demand*. One would hope that, in the presence of new guidance from the project as a whole about the technical direction, FTP Masters and the tag2upload developers would work collaboratively together to improve the entire architecture. Nothing in the GR prevents that; that's never been how we interpret GRs. Second, the specific thing that the GR requires of FTP Master is that tag2upload be allowed to upload source packages signed with its key, following the architecture spelled out here. That architecture includes providing dak, and everyone else looking at the *.dsc file, with the fingerprint of the original tag signer. It does not preclude dak from performing the normal authorization checks for uploads to the archive, only from rejecting packages because they are uploaded through tag2upload. > Post GR, it's not clear to me who gets to decide if changes are needed > without another GR. This was much-discussed after both https://www.debian.org/vote/2007/vote_002 and https://www.debian.org/vote/2007/vote_003. Kurt is authoritative on this point, I think, since it's a question of constitutional interpretation, but my understanding of the project consensus is that a GR is not forever-binding. We all understand that circumstances change in the future and we do not need to strictly follow the exact text of a GR into the indefinite future. It's not a law. The exact time frame is not defined anywhere, but I would think of it as a sort of "slow decay" where, over time, the GR should be seen as a directional statement but the exact architecture should and will change based on new requirements, new issues, and more experience. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
