Re: Three steps we could take to make supply chain attacks a bit harder

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

 



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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux