Re: [RFC] General Resolution to deploy tag2upload
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.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: