On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Dominique Martinet wrote: > > I'm not 100% sure about the theory, but it looks like `autoreconf -fi` > > looks at the 'serial' in the first line of the script. > > The one bundled in the xz sources was marked very high: > > # build-to-host.m4 serial 30 > > But the one in the system (as of f39) is only 'serial 1'. > > > > Artificially lowering the serial back to 0 in the file and running > > `autoreconf -fi` again properly reinstall the one from the system over > > it, but anything higher will keep it... > > > > So if we want to go this route, we should remove the full m4 dir, but > > unfortunately I've seen quite a few projects that depend on non-standard > > m4 scripts so we'll need to fix these as we go... > > Well, it all depends on whether those m4 scripts are really source code or > whether they are autoimported from somewhere like gnulib. True source code > needs to be retained, anything that can be autoimported should be > autoimported at build time. (And upstreams should stop using imported > copylibs to begin with, but that is a different story.) > > > (At which point I'd suggest it's probably faster to convert it all to > > meson or another new shiny, and saner, build system, but getting upstreams > > to agree will be fun) > > CMake! :-) > Funnily enough, xz can also be built with CMake. :) I don't know whether the CMake scripts are complete enough to switch to yet, but we should consider doing it. > >> (2) We should discourage gnulib as much as possible. > >> [...] > >> In the xz case it was a gnulib-derived script which was modified to do > >> the initial injection (original: > >> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). > > > > (Honestly I did compare the backdoored script and the real one this > > morning and I would be hard pressed to say if either is backdoored just > > looking at either version... Admitedly it was 3AM when I looked at it, > > but I don't think it's just a late hour problem) > > That is exactly the problem with autotools code, almost nobody understands > what the heck it does, almost everybody just copies and pastes somebody > else's snippet hoping it does not do bad things. And gnulib is a > particularly ugly piece of the puzzle. > > > Before making each of these safer we should make sshd not link with so > > many things in the first place. > > Indeed. E.g., Arch Linux does not transitively link sshd against liblzma. > Fedora does because of this innocuous-looking patch: > https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch > which is what ultimately allowed this to happen. This drags in libsystemd > for sd_notify, and libsystemd is linked to way too much stuff including > liblzma. Either we need a split libsdnotify that contains only sd_notify, or > we should just stop using sd_notify at all. It increases the attack surface > of daemons a lot just to allow the service to be "Type=notify" rather than > one of the other available approaches. Arch Linux is also systemd-based > nowadays, but still does not link OpenSSH against libsystemd. > This is related to philosophical differences between Arch and Fedora. That said, it probably makes sense for sd_notify to be its own library instead of being part of libsystemd. I'm sure systemd upstream will consider it now. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
