Re: tag2upload (git-debpush) service architecture - draft
Jonathan McDowell writes ("Re: tag2upload (git-debpush) service architecture - draft"):
> 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).
Right. Thanks for your support.
> On Wed, Jul 24, 2019 at 02:56:22AM +0100, Ian Jackson wrote:
> > Please see this blog post to learn about how it works:
> > https://spwhitton.name/blog/entry/tag2upload/
Thanks for the review.
> 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.
Right. This is the way the dgit git server already verifies DM push
permission.
> > * tag2upload service
> > [stuff]
>
> 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.
Indeed.
> > [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?
I know some people have qualms about salsa. (I have some slight
qualms myself). So I think at the very least we (I, in this case)
should leave the door open to competing git hosting service(s).
The technical requirement here is merely basic sanity, and a certain
level of defence against DoS. I think it is not a requirement that a
supported server is operated by Debian. Or even that it continues to
exist - as part of the upload process the git history is transferred
to the *.dgit.d.o git servers, so if the original server vanishes we
still have everything.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: