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 > 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. 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. sshd upstream understood this btw: https://bugzilla.mindrot.org/show_bug.cgi?id=2641 Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
