On Wed, Jul 24, 2019 at 02:56:22AM +0100, Ian Jackson wrote: > I wrote this draft design doc / deployment plan for the tag-to-upload > service, perhaps best summarised by Sean like this: > > We designed and implemented a system to make it possible for DDs to > upload new versions of packages by simply pushing a specially > formatted git tag to salsa.
For the record I am in favour of this as a service. I'm not a dgit user, but I am a salsa user who pushes release tags there and then uploads to the archive. Reducing this to a single action sounds like less work for me and result in less likelihood of me forgetting a step (either the push to salsa, or sometimes an upload). > Please see this blog post to learn about how it works: > https://spwhitton.name/blog/entry/tag2upload/ I've clarified with Ian that despite Sean's blog talking about the debian-keyring package the dgit infrastructure correctly uses the keyring in /srv/keyring.debian.org/ as deployed by DSA on the Debian infrastructure. > TAG-TO-UPLOAD - DEBIAN - DRAFT DESIGN / DEPLOYMENT PLAN > ======================================================= > > Overall structure and dataflow > ------------------------------ > > * Uploader (DD or DM) makes signed git tag (containing metadata > forming instructions to tag2upload service) > > * Uploader pushes said tag to salsa. [1] > > * salsa sends webhook to tag2upload service. > > * tag2upload service > : provides an HTTPS service accessible to salsa's IP addrs > : fishes url and tag name out of webhook json > ! checks that url is basically sane > - retrieves tag data (git shallow clone) > ! parses the tag metadata > ! checks to see if it is relevant > ! verifies signature > ! checks to see if signed by DD, or DM for appropriate package > - obtains relevant git history > - obtains, if applicable, orig tarball from archive > - makes source package > # signs source package and "dgit view" git tag > - pushes history and both tags to dgit git server > - uploads source package to archive > > * archive publishes package as normal The piece of information that I think is missing here (and I've been able to discover in person) is that the "trusted" piece (all the !s) is keeping state during the processing of a particular tag/upload. That is, the trusted component gets handed the tag info, verifies it is sane, hands it off to the untrusted component to fetch + build a source package for, then does as much verification as it can that what it gets back from the untrusted component is the same package/version as expected. Looking at risk factors I think the major ones are dealt with: * The package build is still performed by the buildd, not by this new service, so there shouldn't be exposure to build issues for tag2upload. * tag2upload is making the appropriate checks that the signer of the tag has the right to upload the package to the archive; either is a full DD or is a DM with appropriate DAK ACL rights. * Automated signers for uploads are not new; buildds are already doing this for binary packages. * The complexity is in creating the source package; figuring out the source format type, potentially applying patches etc. This is pushed out to the untrusted component. * Given that the tag signer is independently able to do an upload this does not provide any additional avenue for them to push a nefarious package into the archive. > [1] In principle other git servers would be possible but it would have > to be restricted to ones where we can either avoid, or stop, them > being used as a channel for a DoS attack against the tag2upload > service. If we're hoping to pitch salsa as being the default place for Debian packages to live is limiting this service to salsa not a decent carrot? J. -- "For the effect of psychedelics on the development community, well, there's Enlightenment, isn't there?" -- Adam J. Thornton, asr.
