Re: git & Debian packaging sprint report
On Tue, 2019-07-16 at 08:29 +0100, Sean Whitton wrote:
> We also rely on git for security elsewhere. For example, dak is
> deployed by ftpmasters pushing a signed git tag to salsa; a cronjob on
> ftpmaster then deploys that code. That's relying on SHA-1 in pretty
> much the same way as tag2upload does, AFAICT.
That is true and I don't like it. I should probably add a sha2 hash
somewhere. (Note that we *can* just change it...)
> On Mon 15 Jul 2019 at 10:43PM +02, Ansgar Burchardt wrote:
> > It also has one downside: `git tag` alone won't be enough to generate
> > the required information, but then a special-purpose tool was proposed
> > here already.
> >
> > The client tool could possibly also just create the .dsc and .changes,
> > except for hashes of the compressed files, and the web service just
> > recreate the tarball and compress them. That would require near zero
> > trust in the web service, but still allow developers to no longer upload
> > source packages which might be large. (A bit similar to not having to
> > trust buildds by making packages reproducible.)
>
> This is certainly an interesting proposal and it would be better for
> users than using dput, as you say.
>
> An important advantage of the tag2upload solution over such a thing,
> aside from just the fact that it already exists today, is that it allows
> us to move (slowly!) towards replacing source packages with git trees,
> like the rest of the world has.
>
> git-debpush is such a simple wrapper around git-tag and git-push that
> its users really are uploading only by pushing a signed tag. Your
> proposal would bake source packages back into the upload process in a
> way that will make it harder to ever get rid of them.
No, my proposal allows to stop generating the "source package" as a set
of real files at any given time.
A "source package" generally consists of:
- a set of upstream artifacts (currently one or more tarballs,
signatures); can be the empty set for native packages
- Debian-specific artifacts
- the .dsc artifact (generated from the Debian part); consists of:
- strong cryptographic hashes of all other artifacts
(Checksum-*, Files, ...)
- convenience information extracted from Debian-specific artifacts
(Build-Depends, ...)
Currently we represent all of these as real files that need to be
provided by the uploader.
If you no longer want "source packages" as we have currently, you just
define another representation as the canonical one.
So I would like to just change how developers can provide artifacts to
the archive: upstream artifacts can be specified as either a set of
URLs to retrieve them from or a Git tree; Debian-specific artifacts can
be a Git tree or (for source format 1.0) a diff between two Git trees.
All artifacts provided must be covered by a strong cryptographic hash
which is signed by a developer. The hash must not only cover the Git
tree object itself, but also all content covered by it.
We currently have "tar" as the serialization format covered by the
strong cryptographic hash and, as I value having a representation of
upstream artifacts in the published archive, believe we should continue
to provide the "tar" files. However this is not necessary; we could
instead provide only the Git tree.
Currently this proposal should also allow multi-package repositories,
packaging-only repositories, packages using multiple upstream
artifacts, and ensuring Debian uses the same artifact as upstream. It
does not require any integrity from the VCS system.
I think the .dsc artifact should eventually be split into the two
parts: the list of artifacts (together with strong cryptographic hashes
and where to locate them) signed by the uploader, and the convenience
information extracted from these. The second part should be generated
by the archive software.
Ansgar
Reply to: