Re: tag2upload (git-debpush) service architecture - draft
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.
Reply to: