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

[James Addison]

Hi Otto,

On Thu, 8 Jan 2026 at 19:42, Otto Kekäläinen <otto at debian.org> wrote:
> [ ... snip ... ]
> 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.

Thank you for the guidance - I've refactored the packaging repository
to use the gbp workflow.  It took a little while to understand, but
that does more-or-less make sense to me now - the the ability to
import the sources and for Files-Excluded to be applied consistently
both locally and during Salsa CI is nice.

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

Thanks for this context too.  Although not directly from that, I've
opted to enable pristine-tar in the gbp options, and the resulting
branch (including, currently, I admit, one or two tarfiles/deltas that
were faulty before I applied some fixes) to the repository too.  I
usually want to upload as little as possible -- e.g. the minimal
required to build the intended output -- but in this case, perhaps
providing multiple paths that should all help to confirm the integrity
of the source could be helpful.

Another thing I have in mind is for me to start using a GPG key and to
build a reputation with that and then use it for signing; I'm still
not quite ready for that, but perhaps will be soon.

Regards,
James