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! :-) >> (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. Kevin Kofler -- _______________________________________________ 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
