Systemd haldusmanagerite arendajate seas käib arutelu libsystemd teeki sõltuvuste vähendamise üle, mis seondub mitte ainult systemd komponentidega, vaid ka paljude väliste rakendustega. Näiteks Fedora keskonnas kasutab üle 150 paketi libsystemd sõltuvusi. Arutelu algataja usub, et muude kolmandate osapoolte teekide, mida systemd arendajad ei kontrolli, lisamine libsystemd-sse suurendab oluliselt ründepinda juhul, kui kolmandate osapoolte teegid on kompromiteeritud, nagu juhtus liblzma teegiga.
Lisaks liblzma ja glibc laaditakse libsystemd ka raamatukogud libzstd, liblz4 ja libgcrypt, mille turvalisuse tagamine on kriitilise tähtsusega. Libsystemd pakub juurdepääsu 12 põhilisele API-le (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path ja sd-resolve) ning tekib olukord, kus rakendus, näiteks, mis kasutab libsystemd ainult funktsiooni sd_notify väljakutsumiseks systemd oleku muutusest teavitamiseks või sd_journal andmete logisse kirjutamiseks, seondub kõigi teiste raamatukogude ja API töötlejatega. Lahenduseks on soovitatud jagada libsystemd mitmeks eraldi raamatukoguks, mis vastutavad eraldi API-de eest, võimaldades laadida kolmandate osapoolte sõltuvusi ainult seal, kus need on vajalikud.
systemd arendajad ei pea jagamist mõistlikuks, kuna libsystemd-s olevad töötlejad on omavahel seotud. Jagamine nõuaks tohutut tööd ja tooks kaasa kas efektiivsuse kadumise või koodi dubleerimise vajaduse. Libsystemd mälu kasutuse vähendamiseks on hiljuti vastu võetud muudatus, mis rakendab liblzma, libzstd ja liblz4 teekide dünaamilist laadimist dlopen() abil, olukordades, kus nende funktsioone tõeliselt vajatakse. Sarnane muudatus rakendatakse järgmisest versioonist ka libgcrypt-i jaoks.
Seda otsust on kritiseeritud, kuna selge ja silmatorkava sidumise asemel toimub nüüd kolmandate osapoolte teekide laadimine ebaselgelt, mis muudab diagnostika keerulisemaks, kuna libsystemd API-kutsed ei ole enam ilmselgelt seotud välistest teekidest pärinevate funktsioonidega. Üleminek dlopen() abil laadimisele ei muuda arhitektuuri, vaid varjab vaid välist komponente hooldajate ja kasutajate eest.
Leonard Pottering avaldas kategoorilist vastuseisu ideele jagada libsystemd mitmeks teegiks, kuna see samm keerukaks oluliselt koodi jagamise systemd-s ning nõuab kõigi sisemiste nende töötlejate muutmist avalikeks või nende eraldi staatiliselt iga teegi sisse kompileerimist. Esimesel juhul tekivad probleemid API ja nimede ruumide stabiilsuse säilitamisega, teisel juhul – suureneva suuruse tõttu koodi dubleerimise tõttu.
Järgmise väljaande jaoks rakendatud väliste teekide laadimine ainult vajaduse korral on Leonardiga kokku leppinud kui optimaalne strateegia. Probleemi, mis seisneb dünaamiliselt laetud teekide andmete hankimise keerukuses, pakutakse lahendada, lisades ELF-failidesse täiendavaid välju teabe kohta selliste dünaamiliste sõltuvuste kohta, mida saab töödelda tõrkeotsijate poolt ja mis kuvatakse utiliidi readelf väljundis.
Mis osas libsystemd suure hulga rakenduste sidumisest, soovitas Lennart rakenduste arendajatel mitte proovida laadida libsystemd vaid ühe funktsiooni nimel, vaid rakendada protokolli töötlejat rakenduse tasandil. Näiteks sd_notify() funktsionaalsuse rakendamine on piisavalt triviaalne ja võib mahtuda paarisse koodireale UNIX-soketite (AF_UNIX) kasutamisel. Selline eraldiseisev sd_notify rakendus on alates 2017. aastast saadaval OpenSSH jaoks ning on hiljuti lisatud OpenSSH 9.8 portatiivse haru koosseisu, mille väljaandmine on planeeritud suve keskpaiku.
Allikas: opennet.ru
