[Pkg-samba-maint] Bug#1009726: broken build of samba_4.13.13+dfsg-1~deb11u3 on i386

[Salvatore Bonaccorso]

Hi

On Sat, Apr 23, 2022 at 10:55:28AM +0300, Michael Tokarev wrote:
> Hello!
> 
> It turned out the security-uploaded build of samba on i386 is broken.
> There were several reports about smbd segfaulting at startup or other
> weirdness. This is specific to i386 build, the x64 build is fine (and
> I know nothing about the other architectures).
> 
> An example bugreport is #1006935 - it has several items in the list
> of broken things, but this list is definitely not complete.
> Also #1009855 #1002059.
> 
> I tried to rebuild the same source package in a local clean bullseye
> chroot, apparently with the same versions of everything, in the same
> environment, and I'm getting *significantly* different binaries.
> Updating just one package - switching from debian-built one into my
> locally-built one immediately fixes the problem for me, samba starts
> working as it should without weird errors or crashes.
> 
> The issue at hand seems to be the usage of python hashes in samba
> build procedure for everything including lists of include or library
> paths, lists of object files for link and everything. By default,
> python hashes are randomly-ordered, - this means the order of all
> this is unpredictable and each time we're getting VERY different
> binaries.
> 
> Since samba overrides many system-provided functions, and the order
> of objects to link is important, in this particular build we got
> an order which made it use wrong functions in the end, and the
> thing started to behave in a weird way.
> 
> Upstream tried to fix this by using PYTHONHASHSEED=1 (which *still*
> gives an order which depends on the architecture, but this is a
> different issue).
> 
> So we have to fix this one in bullseye.
> 
> I already prepared a bullseye-pu version of samba - #1009726 -
> the bug#), which does not include this fix. I'll update it today
> (the fix is trivial) and resubmit.  The bullseye-pu version has
> some more fixes than is usually okay to bring to security@ but
> most of them are worth the effort.
> 
> Now since the prob is quite serious, maybe we can fix this some
> faster way?

To comment on this speaking form the security team perspective: We
discussed it shortly and came to conclusion that it would be fine to
just include this fix in the proposed update for the next bullseye
point release without need of an out of order DSA for samba to address
this. Affected users running on i386 migh then fetch earlier
the update from the proposed-updates suites and so not forcing the
working amd64 samba installations for another update. We think the
major installation base for samba servers will not be on i386.

Having this updat prepared for the next point release lays ground for
future samba updates needed via security. So many thanks for hinving
done this fair amout of work on your shoulders!

Regards,
Salvatore