Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Sam Hartman writes ("Re: tag2upload service architecture and risk assessment - draft v2"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > The mapping from git tag to .dsc is nontrivial.  git tag to
> > .dsc construction (or verification) is complex and offers a
> > large attack surface to the incoming source code.  It ought not
> > to be done near a powerful key such as the dak master archive
> > signing key.
> 
> It's nontrivial in your design.

It is true that there are other possible approaches.
Key benefits of the present proposal are:

1. The uploader can continue to use their existing best practice git
   repository layout, their existing git workflow, and so on.  So no
   disruption or degradation of maintainer experience.

2. The Debian ftp archive continues to publish a .dsc like those from
   current best practice approaches.  So no disruption or degradation
   to the experience of downstreams of the archive.

3. tag2upload publishes the git history in accordance with current
   best practices (ie, maintainer view on salsa and dgit view on dgit
   git server).  So no disruption or degradation to the experience of
   current git users.

4. The uploader does not need to work with, or transfer or keep, any
   tarballs (unless this is needed because of upstream practices). [+]

5. The instruction to upload is a plain signed git tag pointing at
   the commit to be released. [*]

1-3 are "no degradation compared to existing approaches".

4-5 are "this is an ordinary git operation, not a bodge where we
         transport other data embedded in git objects".

That the conversion to a .dsc is nontrivial seems to follow directly
from the above objectives.  It arises because existing conversions of
maintainer's git commits to source packages are already complex.

Oh, and of course:

0. It exists.

Ian.

[+] Publishing pristine upstream tarballs would obviously involve
working with tarballs at least some of the time.  It is feasible with
my approach but not yet implemented.

[*] Obviously there has to be some extra information in the tag, such
as instructions about which distro and suite to upload to.  But by a
"plain" git tag we mean that any such information is short and flat
and straightforward, so it could be generated by hand, or by a variety
of tools, etc.

-- 
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.