Scott Kitterman <[email protected]> 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. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
