Bug#963788: systemd: please make user order and ids of systemd and systemd-timesyncd reproducible

[Balint Reczey]

Control: reassign -1 dpkg 1.20.3
Control: affects -1 systemd

Hi All,

I agree with Chris, it would be better to find an archive-wide
solution than adding a hack to the two binary packages of systemd.
As I see the postinst scripts themselves are correct and the
nondeterminism comes from the order of executing them which is done by
dpkg, thus I'm reassigning this bug.

Cheers,
Balint

On Tue, Jun 30, 2020 at 12:51 AM Chris Lamb <lamby at debian.org> wrote:
>
> [adding reproducible-builds at lists.alioth.debian.org to CC]
>
> Johannes 'josch' Schauer wrote:
>
> > This is problem for reproducible installations because the exact same
> > package set, consisting of systemd and systemd-timesyncd can result in a
> > different system after installation.
>
> I remember working on related issues in Tails which releases
> bit-for-bit reproducible ISO images.
>
> In the end, we went with a horrible post-build script that swapped
> group IDs that were assigned non-deterministically due to the
> arbitrary execution order of the postinst scripts.
>
> I mention this here to encourage us exploring an archive-wide solution
> rather than fixing every time it comes up.
>
> This is a particularly good candidate for a general solution as, in my
> hard-won experience:
>
>  a) The non-determinism can happen infrequently and thus does not appear
>     even in extensive testing.
>
>  b) There was no way to flush out the problem in CI (compare using
>     disorderfs to reverse your filesystem ordering to
>     deterministically flush out non-deterministic behaviour or similar
>     tricks.)
>
>  c) Each test build run can take a significant amount of time.
>
>  d) The packages could be entirely unrelated. As in, it could have
>     been between entirely different packages that could not have been
>     fixed by adding a relationship.
>
> (Tails also has unrelated reasons for having persistent GIDs across
> builds with different inputs. I would immediately concede that
> these are out of scope for Debian itself to resolve.)
>
> I'm not sure exactly where this change could be made (dpkg? apt?) as I
> lack a confident understanding of the exact roles of those two tools,
> but I am assuming that one of these is *eventually* deciding whether to
> run the postinst for systemd or systemd-timesyncd first.
>
>
> Regards,
>
> --
>       ,''`.
>      : :'  :     Chris Lamb
>      `. `'`      lamby at debian.org chris-lamb.co.uk
>        `-
>


-- 
Balint Reczey
Ubuntu & Debian Developer