Ing antarane pangembang manajer sistem systemd, ana diskusi babagan nyuda dependensi perpustakaan libsystemd, sing ora mung nyambung menyang komponen systemd, nanging uga akeh aplikasi eksternal. Contone, ing Fedora, luwih saka 150 paket nggunakake libsystemd ing dependensi. Inisiator diskusi percaya yen nambah perpustakaan pihak katelu tambahan menyang libsystemd sing ora dikontrol dening pangembang systemd nambah permukaan serangan yen ana perpustakaan pihak katelu sing dikompromi, kaya sing kedadeyan karo perpustakaan liblzma.
Saliyane liblzma lan glibc, libsystemd uga ngemot libzstd, liblz4 lan libgcrypt, keamanane dadi kritis. libsystemd nyedhiyakake akses menyang 12 API dhasar (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd - path lan sd-resolve) lan kahanan muncul ing ngendi aplikasi, contone, nggunakake libsystemd mung kanggo nelpon fungsi sd_notify kanggo ngandhani systemd babagan owah-owahan negara utawa sd_journal kanggo nulis data menyang log, pranala karo kabeh perpustakaan liyane lan pawang API. Minangka cara metu, ngajokaken pamisah libsystemd menyang sawetara perpustakaan kapisah tanggung jawab kanggo API kapisah, kang bakal ngidini dependensi pihak katelu dimuat mung ing ngendi padha needed.
Pangembang systemd nganggep pemisahan kasebut ora cocog, amarga panangan sing ana ing libsystemd saling nyambungake. Pemisahan mbutuhake akeh karya lan bakal nyebabake efisiensi utawa mbutuhake duplikasi kode. Kanggo nyuda jejak memori, libsystemd bubar diganti kanggo mbukak perpustakaan liblzma, libzstd, lan liblz4 kanthi dinamis nggunakake panggilan dlopen () ing kahanan sing fungsine pancen dibutuhake. Pangowahan sing padha bakal ditindakake kanggo libgcrypt wiwit rilis sabanjure.
Kaputusan iki wis dadi obyek kritik, amarga tinimbang ngubungake eksplisit lan katon, loading perpustakaan pihak katelu saiki bakal rampung implisit, kang bakal complicate diagnostik, amarga sambungan saka libsystemd API telpon karo telpon kanggo fungsi saka perpustakaan external ora. ketok. Ngalih kanggo loading nggunakake dlopen () dhewe ora ngganti arsitektur, nanging mung ndhelikake komponen external saka maintainers lan kedhaftar.
Lenart Pottering ora setuju banget karo ide kanggo pamisah libsystemd dadi sawetara perpustakaan, amarga pamindhahan kasebut bakal nggawe rumit enggo bareng kode ing systemd lan mbutuhake kabeh pawang internal umum utawa dikompilasi kanthi statis menyang saben perpustakaan. Ing kasus sing sepisanan, bakal ana masalah kanggo njaga stabilitas API lan spasi jeneng, lan ing kaloro bakal nambah ukuran amarga duplikasi kode.
Dilaksanakake kanggo rilis sabanjure, ngemot perpustakaan eksternal mung yen perlu dirasakake dening Lenart minangka strategi optimal. Disaranake kanggo ngatasi masalah nambah kerumitan kanggo entuk data babagan perpustakaan sing dimuat kanthi dinamis kanthi nambah kolom tambahan menyang file ELF kanthi informasi babagan dependensi dinamis kasebut, sing bisa diproses dening debugger lan ditampilake ing output sarana readelf.
Babagan ngubungake nomer akeh aplikasi karo libsystemd, Lenart dianjurake supaya pangembang aplikasi ora nyoba mbukak libsystemd kanggo fungsi siji, nanging ngleksanakake handler protokol ing tingkat aplikasi. Contone, implementasine saka sd_notify () fungsi cukup ora pati penting lan bisa rampung ing sawetara baris kode nalika nggunakake soket UNIX (AF_UNIX). Implementasi kapisah sd_notify sing padha wis kasedhiya kanggo OpenSSH wiwit 2017 lan bubar diadopsi menyang cabang portabel OpenSSH 9.8, rilis sing dijadwalake ing pertengahan musim panas.
Source: opennet.ru
