On Sunday, June 23, 2024 1:16:38 PM EDT Russ Allbery wrote: > Scott Kitterman <debian@kitterman.com> writes: > > On Sunday, June 23, 2024 11:48:09 AM EDT Russ Allbery wrote: > >> As mentioned in the summary, I believe we've found a resolution to this > >> problem provided that the FTP team is willing to implement the protocol > >> I described in dak, which Ansgar seemed supportive of. That allows > >> them to do both the authentication and authorization check directly on > >> the Git tag signed by the uploader, which means the trust extended to > >> tag2upload is then almost precisely equivalent to the trust extended to > >> a binary buildd: start from an independently-verified > >> maintainer-signed thing and produce a build artifact. > > > > I will confess having trouble keeping track of all the back and forth. > > After that, it was my impression that the press was on to deploy as is. > > So far as I know, no one in this discussion has ever asked for the FTP > team to deploy tag2upload. The only hard request of the FTP team is to > not block uploads made with it. If the FTP team refuses to do any work > whatsoever on anything related to tag2upload, it is still possible to > deploy it (with some assistance from other teams such as DSA, of course). > > There are some very obvious and relatively minor changes to dak that would > make Debian as a whole more secure and that I would hope the FTP team > would be willing to make, such as a separate keyring for tag2upload that > only allows source packages similar to the separate keyring for buildds > that only allows binary packages. One of them is to allow tag2upload > uploads to contain an additional file holding the original signed Git tag, > and then dak can choose to repeat the authentication and authorization > checks on that tag, verify that the fields in the *.dsc match the tag, > etc. tag2upload can be deployed without those changes, but it would be > better if those changes were also made. > > If FTP team is willing to incorporate those changes into dak but doesn't > want to write them, I am sure that we can find volunteers to do so. That > volunteer might be me, for example; implementing something practical would > be a nice break from arguing about things. > > > Regardless, I think the major point is that running on a DSA managed > > host doesn't necessarily equate to DSA running the service. > > Yes, I think everyone agrees with this and no one expected DSA to run the > service. Maybe I'm wrong, in which case someone please correct me. > Sorting out exactly what "run" means and how labor is divided is something > that I assumed they would work out with DSA once there was a path forward > for deploying the service. > > I personally don't know what the standard model for Debian infrastructure > services is, but I believe Ian has already been through this process with > the dgit-repos service and knows how it works. > > > I think who is going to run the tag2upload service and if some > > delegation for doing so is appropriate are both questions that aren't > > answered by DSA will run the host. > > I believe the answer to who is going to run the tag2upload service is Ian > and Sean. Thanks. I guess I misunderstood the buildd analogy. I appreciate the clarification. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.