Re: xz backdoor

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

 



On 02. 04. 24 14:17, Lennart Poettering wrote:
On Di, 02.04.24 14:04, Petr Menšík (pemensik@xxxxxxxxxx) wrote:

I am not convinced dlopen will it make secure in the end. I am not sure this
is a good solution. dlopen makes those dependencies non-obvious from
packaging side and non-visible from ldd or similar checking programs.

I think it should be considered to offer more than one dynamic
library.
It was considered. To the point that a decade ago, libsystemd
originally was split up. But it was awful to maintain.

But let's not repeat this discussion here. Read up here:
https://github.com/systemd/systemd/issues/32028

Oh, I hate the way discussions are moderated at systemd upstream. I would prefer to discuss here.

It appears you do not want to make it simple to use just notify lib. But luckily it does not have to be maintained by systemd team. Yes, the protocol is trivial. But it still needs to handle conditions when it does not run under systemd. When it does, but error occurs. While number of lines required are very low, it would have need to be duplicated many times in many services. More or less the same code.

It is apparent either everyone will implement it themselves or systemd-independent project needs to provide just limited sd_notify shared library. At least it needs documentation. Indication it implements sd_notify in some way is nice to have bonus.

For example most services I maintain links to libsystemd just
because it wants sd_notify calls in their services. Without any
proof I would expect quite many services would have similar
problem. Could be perhaps libsystemd broken into few more dynamic
linked libraries? I somehow doubt any kind of compression is needed
for sd_notify calls.

Could be even smaller library libsystemd-notify linked from libsystemd,
which would allow end applications to explicitly declare they need more
limited set of functions?
Why link? I'd really just suggest people to implement the trivial
client on their own. It's a trivial protocol for a reason: so that
people can implement it natively in their language and framwork
without bothering with our upstream libsystemd.
Because the number of applications solving the same problem is rather high. It is not issue to be solved in about 3 projects. There are dozens of daemons, which should implement the same functionality. Common base even with a tiny library still makes a sense to me. Especially if most of them linked unnecessarily to libsystemd and thought that was the best option.

use libsystemd if you link against it anways and hack in C, or if you
really don't are about the extra dep for a single function, but
otherwise, why would you use the lib?

It *literally* is just sending a text string "READY=1" in an AF_UNIX
datagram to a socket whose path is provided to you in the
$NOTIFY_SOCKET env var. Anyone with a moderate understanding of UNIX
APIs should be able to hack that up in a a few lines of code. It's a
protocol I can summarize and explain in *one* frickin' sentence.

Yes, I admit, it is simple line oriented protocol. But you need to get notify socket path, handle failures when opening it. You need to know what to write there, so also documentation is needed. Man page for sd_notify is nice. Implementation of sd_notifyf() function would not be trivial. While it is not difficult to get right, it does not make sense to have over 15 different implementations, when it can share the same code. When you want to include also error messages, it certainly becomes more than few lines.

Function pid_notify_with_fds_internal from ./src/libsystemd/sd-daemon/sd-daemon.c certainly is not just few lines, as suggested. Should I ask why, if not necessary? It seems whole sd-daemon.c has 775 lines, which would be nice to have separate library. Things missing are some helpers. Socket activation is not as needed as core sd_notify, but might be a good addition. Still needs just environment and pointer to ints. No unwanted dependencies, I think that would make a nice standalone shared library. It provides everything I would need in common service.

sshd upstream understood this btw:

https://bugzilla.mindrot.org/show_bug.cgi?id=2641

Lennart

--
Lennart Poettering, Berlin

I think they preferred having fast fix over having long-term sustainable solution. I haven't seen offer to provide libsystemd-notify library with minimal dependencies, which they kindly refused. They preferred bundled code over systemd bloat in comment #13. I haven't seen bloat-less library considered in the bug, but might have missed it?

The question is, how should be the separate library called. libsystem_notify? Ideas for a better name?

Compat include header to make it otherwise unmodified with libsystemd would be nice as well.

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
_______________________________________________
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