Paul Gevers writes ("Bug#1085152: dgit: support lightweight 
no-change-source-only uploads"):
> 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):

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.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Reply via email to