On Friday, June 14, 2024 2:45:55 PM EDT 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.
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. > > 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. Which means that in the future, the tag2upload developers can make whatever changes they want and the FTP team is required to accept them? > > 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. Thanks. That's slightly before my time, so I didn't know about it. I think it makes sense. 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. 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? It doesn't feel like this is complete enough to tie the FTP Team's hands over it. I have some questions about the security review, which I will ask in that thread, so I won't go into those here. Scott K
signature.asc
Description: This is a digitally signed message part.
