Igen valószínű, hogy Ön is hallott már a Log4j-problémákról, amelyek oly sok alkalmazást és internetes szolgáltatást érintettek az elmúlt két hétben. Ennek a kritikus hibának a Minecraft konzolüzenetekben való véletlen felfedezése (a Minecraft játékkliensbe írt üzenet lehetővé teheti, hogy valaki kódot futtasson egy Minecraft szerveren) a Log4j nevű rendkívül népszerű Java naplózókönyvtár használata közben arra késztetett sok informatikai céget és olyan vállalatot, amely szoftveralkalmazásokat használ, hogy leellenőrizze, hogy a probléma érinti-e a vállalat szoftverét, a tárolt szolgáltatásokat, a belső webhelyeket és bármely más használati esetet.
Az érintett szoftveralkalmazások listája (például itt van egy) meglehetősen figyelemre méltó, mert annak ellenére, hogy valamelyes veszített a lendületéből az utóbbi években, a Java még mindig a világ egyik legnépszerűbb nyelve és az is marad, a JVM pedig az egyik legnépszerűbb futtatási végrehajtási (runtime execution) környezete.
RAD Studio natív kód Java-függőség nékül
Nézzk meg mit jelent mindez az Embarcadero és különösen a RAD Studio szempontjából? Közvetlenül, nem sokat. A Delphiben vagy a C++Builderben épített szoftverek semmilyen módon nem használnak Java-t, és semmilyen módon nem támaszkodnak rá (az Android-alkalmazások kivételével), ezért nem is használják a Log4j-t. Általánosságban elmondható, hogy a Delphi és a C++Builder natívan lefordított alkalmazásokat hoz létre, amelyek kevésbé vannak kitéve a végrehajtási környezeti problémáknak (itt a Java, .NET vagy JavaScript végrehajtási környezetekre gondolunk). Ebben az esetben azonban a probléma nem a végrehajtási környezetben volt, hanem egy népszerű könyvtárban, és a RAD Studio fejlesztők, bármely más fejlesztői közösséghez hasonlóan, ugyancsak gyakran használnak kiegészítő, harmadik féltől származó könyvtárakat vagy összetevőket.
Tehát még egyszer a lényeg: a Delphibe vagy a C++Builderbe (vagy általában a C++-ba) beépített webszervert vagy webszolgáltatást nem érinti a Log4j probléma. Ugyanez vonatkozik természetesen az ASP.NET-ben, Pythonban vagy PHP-ben készített webes alkalmazásokra is. A probléma kifejezetten a Java nyelven írt szoftverekre vonatkozik.
Visszatérve a Delphihez és a C++Builderhez, biztonság szempontjából a fordított (compilied) kód segít, de nem mindig elegendő. Az is nagyon fontos, hogy csak olyan könyvtárakat és komponenseket használjunk, amelyekben teljes mértékben megbízhatunk. Ezenkívül az is fontos, hogy a fejlesztő a kódot már úgy írja, hogy különös figyemet fektet a biztonságra. Az úgy nevezett copy-and-paste kódolás rengeteg veszély forrása lehet (bár jelen esetben közvetlenül nem felelős a Log4j problémáért).
A teljes angol nyelvű cikkért kattintsanak ide