Bug#1085152: dgit: support lightweight no-change-source-only uploads

[Paul Gevers]

Package: dgit
Version: 11.11
Severity: wishlist

Hi Ian, Sean,

While discussing our Release Team work with Graham, we thought it might
be a nice feature by the dgit infrastructure if it could support
lightweight (i.e. no local download of the source) no-change-source-only
uploads to the archive. Two usecases come up in my mind (but I bet there
are more):
* Fix an arch:all binary upload (I happen to do this regularly, with the
aid of a script that powers dgit)
* Complement the binNMU facilities we have for the Release Team, but
without some of the binNMU drawbacks:
* Architectures in sync
* Automatic migration checks (obviously this could be fixed on the
Release Team side of things too)
* Reproducibility people happier (they don't like binNMUs weird
changelogs if I recall correctly)

Paul

[Ian Jackson]

Post by Paul Gevers
While discussing our Release Team work with Graham, we thought it might
be a nice feature by the dgit infrastructure if it could support
lightweight (i.e. no local download of the source) no-change-source-only
uploads to the archive. Two usecases come up in my mind (but I bet there

Hi. Thanks for this suggestion.
I think this could be a function of the tag2upload service.

Do we, in this scenario, mind downloading a git clone of the package?
I think it would be best if we could avoid it.

How does the person doing this indicate their intent ?

They could make an OpenPGP signature which would say something like
"please no-source-upload package X, version A, to suite S,
as version B".

Or, in principle, there could be a web self-service system, but that
has many Implications and fits into the various data models less well.

That OpenPGP signature could be a signed git tag. To make a tag, the
tagger does *not* need a complete copy of the code. They need the
commitid, but that's readily available if the package is on
dgit-repos.

I think this could be a mode of git-debpush, or an allied utility.

Presumably the tag2upload service would retrieve the previous
version's archive/ tag and check that it had the same commitid. It
should also check the ftpmaster API to get the hash of the
corresponding .dsc, and fish out the Dgit: field.

(This approach trusts that we won't find that both dgit-repos and
ftpmaster API are colmpromised. Neither the authoriser, nor the t2u
service, can reliably verify the signature on the previous archive/
tag. Debian has no post-hoc audit capability for upload signatures.)

Also, this only works for packages where the most recent version is on
dgit-repos. Currently that's packages uploaded with dgit, and, soon,
t2u. I'm hoping that t2u adoption will become widespread. At that
point I think it would be a good idea to start importing all uploaded
packages into dgit-repos automatically.

Anyway, I think we should focus on t2u service deployment for "normal"
uploads first - but having this kind of future scenario in mind is a
good think.

After t2u is deployed I think we should probably try to widen the
t2u/dgit team. (And we as t2u service operators should seek a DPL
delegation.) There will be more space to explore this kind of idea.

Ian.