On Sat, Mar 30, 2024 at 12:10 PM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > On Sat, Mar 30, 2024 at 02:44:32PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Mar 30, 2024 at 08:23:48AM -0400, Neal Gompa wrote: > > > On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel > > > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > (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! :-) > > > > Meson outclasses CMake in functionality, clarity, and brevity. > > I doesn't make sense to consider switching to CMake at this point. > > Which is the better build system doesn't much matter here, as they all > let you run shell scripts so source level backdoors could be inserted > in all of them. > > The big difference they all have over autoconf is that they don't > usually distribute a giant obfuscated (basically binary) shell script. > > We can fix autoconf now by running autoreconf and we don't need to > boil the ocean to do so. > > > > > 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. :) > > > > I don't think a separate library would be particularly useful. > > sd_notify() as used by sshd just writes a static string to a unix > > socket. This can be implemented in ~10 lines of C, including error handling. > > > > If that is the _only_ thing needed from libsystemd, then open-coding it > > is a good option. I guess it'd make sense for systemd to provide a header > > file that provides a reference documentation as an inline function. > > I think systemd should do this, just so we have one implementation, > and not loads of buggy ones. > > > One thing which is happening, mostly for unrelated reasons, it that > > systemd code is being changed to use dlopen() for various libraries which > > are usually not needed at runtime. The primary motivation for this is to > > omit such libraries from the initrd. But this also helps with overlinking. > > > > In systemd git main, libsystemd is only linked to libc, libcap, > > and libgcrypt + libgpg-error. A pull request to convert that that last > > pair to dlopen is under review. > > Also a good change, thanks. > Note that dlopen() doesn't fix the problem of the giant libsystemd in the first place. It just obfuscates the true dependency graph of libsystemd. Long ago (I think like ~10 years ago), libsystemd was actually several separate smaller libraries. Perhaps we could consider asking upstream to switch back to that model? -- 真実はいつも一つ！/ 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
