Mes zhvilluesve të menaxherit të sistemit systemd po diskutohet çështja e zvogëlimit të varësive të bibliotekës libsystemd, e cila lidhet jo vetëm me komponentët e systemd, por edhe me shumë aplikacione të jashtme. Për shembull, në Fedora më shumë se 150 paketa përdorin libsystemd si varësi. Nismëtari i diskutimit vlerëson se përfshirja në libsystemd e bibliotekave shtesë të palëve të treta, të cilat nuk kontrollohen nga zhvilluesit e systemd, e rrit ndjeshëm sipërfaqen e sulmit në rast komprometimi të këtyre bibliotekave, siç ndodhi me bibliotekën liblzma.
Përveç liblzma dhe glibc, në libsystemd ngarkohen edhe bibliotekat libzstd, liblz4 dhe libgcrypt, ruajtja e sigurisë së të cilave po bëhet një detyrë me rëndësi kritike. libsystemd ofron qasje në 12 API bazë (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path dhe sd-resolve), dhe krijohet një situatë ku një aplikacion, për shembull, që përdor libsystemd vetëm për të thirrur funksionin sd_notify për të njoftuar systemd për ndryshimin e gjendjes, ose sd_journal për të shkruar të dhëna në log, lidhet me të gjitha bibliotekat dhe përpunuesit e tjerë të API-ve. Si zgjidhje propozohet ndarja e libsystemd në disa biblioteka të veçanta, secila përgjegjëse për API të caktuara, gjë që do të lejojë ngarkimin e varësive të palëve të treta vetëm aty ku ato janë të nevojshme.
Zhvilluesit e systemd mendojnë se ndarja nuk është e arsyeshme, pasi përpunuesit e pranishëm në libsystemd janë të ndërlidhur. Ndarja do të kërkonte një punë gjigante dhe do të çonte ose në humbje efikasiteti, ose në nevojën për të dubluar kodin. Për të ulur përdorimin e memories, në libsystemd së fundi është pranuar një ndryshim me zbatimin e ngarkimit dinamik të bibliotekave liblzma, libzstd dhe liblz4 me anë të thirrjes dlopen(), në rastet kur funksionet e tyre janë vërtet të nevojshme. Një ndryshim i ngjashëm do të zbatohet edhe për libgcrypt duke filluar nga publikimi i ardhshëm.
Kjo zgjidhje është bërë objekt kritikash, pasi në vend të lidhjes së qartë dhe të dukshme, ngarkimi i bibliotekave të palëve të treta tani do të kryhet jo në mënyrë eksplicite, gjë që do ta vështirësojë diagnostikimin, sepse lidhja mes thirrjeve API të libsystemd dhe thirrjeve të funksioneve nga bibliotekat e jashtme nuk do të jetë e qartë. Në vetvete, kalimi te ngarkimi me ndihmën e dlopen() nuk e ndryshon arkitekturën, por vetëm i fsheh komponentët e jashtëm nga mirëmbajtësit dhe përdoruesit.
Lenart Poettering ka shprehur mospajtim kategorik me idenë e ndarjes së libsystemd në disa biblioteka, pasi një hap i tillë do ta ndërlikonte ndjeshëm ripërdorimin e kodit në systemd dhe do të kërkonte që të gjithë përpunuesit e brendshëm të bëheshin publikë ose të përfshiheshin veçmas në mënyrë statike në secilën bibliotekë. Në rastin e parë do të lindnin probleme me ruajtjen e stabilitetit të API dhe me hapësirat e emrave, ndërsa në të dytin do të rritej madhësia për shkak të dublimit të kodit.
Ngarkimi i bibliotekave të jashtme vetëm sipas nevojës, i zbatuar për versionin e ardhshëm, perceptohet nga Lenart si strategjia optimale. Problemi i ndërlikimit të marrjes së të dhënave për bibliotekat e ngarkuara dinamikisht propozohet të zgjidhet duke shtuar në skedarët ELF fusha shtesë me informacion për varësi të tilla dinamike, të cilat mund të përpunohen nga debugerët dhe të shfaqen në daljen e mjetit readelf.
Sa i përket lidhjes së një numri të madh aplikacionesh me libsystemd, Lenart u rekomandoi zhvilluesve të aplikacioneve të mos përpiqen të ngarkojnë libsystemd vetëm për një funksion, por të zbatojnë përpunuesin e protokollit në nivel aplikacioni. Për shembull, zbatimi i funksionalitetit sd_notify() është mjaft trivial dhe mund të kufizohet në disa rreshta kodi duke përdorur UNIX sockets (AF_UNIX). Një zbatim i tillë i veçuar i sd_notify është i disponueshëm për OpenSSH që nga viti 2017 dhe së fundmi është pranuar në degën portable të OpenSSH 9.8, publikimi i të cilit është planifikuar për në mes të verës.
Burimi: opennet.ru
