[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1009726: broken build of samba_4.13.13+dfsg-1~deb11u3 on i386



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?

Thanks,

/mjt


Reply to: