[Debian-salsa-ci] Repacking source package files in Salsa-CI

[Otto Kekäläinen]

..
> > In that case you can look at
> > https://salsa.debian.org/go-team/packages/ratt/-/tree/debian/latest/debian
> > for example of how I've done it. The debian/watch file simply points
> > to the upstream git HEAD, and the debian/gbp.conf has this note:
> >
> > # Ratt has no tags or releases at https://github.com/Debian/ratt
> > # Instead, merge latest commit from 'master' on 'upstream' and tag it
> > # as the imported version
> > #upstream-vcs-tag = v%(version%~%-)s
> >
> > If upstream does not do any releases, there are no security features
> > to use (detached signatures nor signed git tags) so audit trail is
> > inevitably going to be weak, but you should still be able to use `gbp
> > import-orig --uscan` that runs `uscan` and applies the
> > debian/copyright:Files-Excluded` automatically.
> >
> > i am not sure about all the details, I haven't done a package with no
> > releases _and_ repacking in the same combo. In general though I
> > recommend sticking to a workflow where simply running `gbp import-orig
> > --uscan` works as the more you have manual fiddling in the import, the
> > less likely it will be that the next person or you yourself in a year
> > from now are able to keep the package uniform and repeat the exact
> > same way of importing.
>
> Thanks again Otto.
>
> If I understand this correctly: I should be able to rework the
> packaging so that the git sources are imported into a source tarball
> (sans Files-Excluded content) from upstream HEAD by uscan, and -- from
> what I follow of the uscan documentation -- that process can also add
> the appropriate year-month-day + git commit ID to the changelog.  The
> changelog/packaging naming has so far been a process I've followed
> manually, so using uscan instead would be much simpler, more
> repeatable, less error-prone, and also solve the Files-Excluded
> repacking problem.

The end result should be so that when uscan runs alone, it will fetch
the upstream sources and repacks it automatically. When you run `gbp
import-orig --uscan` it will likewise get the exact same thing, and
git-buildpackage will additionally deposit it in git in the correct
way.

Debian does actually not have a proper software provenance system and
the upstream source SHA256 sum or similar is not recorded anywhere in
debian/*. The provenance comes from the fact that when I run uscan on
your package I should get the same results. Thus it is important that
the contents of debian/ is correct and you don't do any "manual"
additional tricks.

The short commit id in the package name is just a convention and not
actual security feature, but I do recommend you use it. The state of
the packaging in
https://salsa.debian.org/go-team/packages/ratt/-/tree/debian/latest/debian
is recent and reviewed, so if you copy conventions from it, the end
result shloud be pretty good.

> I'll think about whether there is anything I could do in addition to
> mitigate the security/provenance question.  Provided that the filtered
> tarball is pushed to a git branch in Salsa, and that the changelog
> entries have a timestamp and a sufficiently-long git SHA prefix, I
> figure it's not terrible -- but maybe there are some other simple
> safety mechanisms that could prevent basic problems and/or add
> integrity.

Debian is a bit complex in this regard, and as said e.g. the upstream
SHA256 is not stored anywhere (unlike e.g. Fedora or Arch does it),
but the end result can still be audited by comparing the uploaded
final result to packaging git contents to see what the packager did,
and to upstream to see what came from upstream. A long explanation of
that can be found at
https://optimizedbyotto.com/post/xz-backdoor-debian-git-detection/.