Log4j

[mash_gh4]

Das ursächliche Problem sehe ich nicht bei Java an sich, sondern an den Leuten, die es nutzen.

ja -- da gebe ich weitestgehend recht.

das gegenständliche problem hätte wirklich in fast jeder anderen programmiersprache in gleicher weise auftreten können, weil das ganze höchstens am rande mit technischen eigenheiten od. möglichkeiten von java selbst zu tun hat.

allerdings macht es natürlich schon einen unterschied, in welcher sprache etwas geschrieben ist, wenn es darum geht, wo entsprechende libraries eingesetzt werden und welches vertrauen man ihnen entgegen bringt.

und was diesen punkt angeht, ist es gar nicht einfach, die rolle von java eindeutig zu charakterisieren.

java ist sicher nicht die allerschlimmste bedrohung für den guten geschmack -- PHP, java script u.ä. sind da weitaus bedrohlicher --, aber es ist halt leider doch eine sprache, die nicht nur im stumpfsinnig kommerziellen umfeld noch immer sehr populär ist, sondern vor allem auch häufig in ausbildungszusammenhängen unterrichtet wird, und deshalb natürlich auch sehr oft von unerfahreneren kollegen recht unreflektiert in ihren ersten anfänglichen versuchen genutzt wird. aber natürlich gibt's auch jede menge richtig gute software, die damit fabriziert wurde. trotzdem mach ich aus meinen erfahrungen heraus mittlerweile einen weiten bogen darum herum, was aber im freien softwareumfeld ohnehin ganz gut geht, ohne sich groß einschränken zu müssen.

ich bin allerdings nicht ganz so pessimistisch wie du, was die weiterentwicklung der computersprachen angeht. auch dort gibt es immer wieder wellen des nachdenkens und der korrektur, die auf gravierende missstände und fehlentwicklungen zu reagieren versuchen.

ich selber benütze mittlerweile hauptsächlich rust zum programmieren (python fast nur mehr für die schnellen skizzen), um mich in dieser hinsicht ganz bewusst um ein wenig verbesserung und vorbildlichkeit zu bemühen, auch wenn's manchmal vergleichsweise anstrengend und nicht ganz so produktiv ist.

aber wie gesagt, der hier zur debatte stehende fehler hätte in wahrheit genauso in einer C, C++, Go od. Rust library stecken können. dass es diesmal gerade java ist, verzerrt nur den kreis der betroffenen programme und ihrer nutzer ein wenig -- erklärt allerdings vielleicht auch ein wenig die schadenfreude auf seite jener, die java und daran geknüpfte firmen- und lizenzkultur bzw. erwartungen im kommerziellerem softwareumfeld nicht unbedingt schätzen.

[TheBubble]

sondern vor allem auch häufig in ausbildungszusammenhängen unterrichtet wird, und deshalb natürlich auch sehr oft von unerfahreneren kollegen recht unreflektiert in ihren ersten anfänglichen versuchen genutzt wird.

Java wurde in der Lehre verwendet, ist in vielen Veranstaltungen aber wieder ersetzt worden. Nach Java kam Python, vorher war es u.a. Modula-2. Es spielt aber letztlich keine Rolle, da Lehrzwecke andere Anforderungen haben, als man sie bei der Entwicklung von (kommerzieller) Anwendungssoftware hat.

[mash_gh4]

Java wurde in der Lehre verwendet, ist in vielen Veranstaltungen aber wieder ersetzt worden. Nach Java kam Python, vorher war es u.a. Modula-2. Es spielt aber letztlich keine Rolle, da Lehrzwecke andere Anforderungen haben, als man sie bei der Entwicklung von (kommerzieller) Anwendungssoftware hat.

wenn ich mich hin und wieder nach arbeit umsehe, fällt mir natürlich schon auf, wie gefragt java in der realen wirtschaftswelt da draußen noch immer ist. damit verhält es sich offenbar ganz ählich wie der videotechnik die in den rundfunkanstalten genutzt wird. auch dort hält man qualitätsstandards und auslieferungsformaten fest, die heute jedem einigermaßen engagierterter amateur höchstens ein kopfschütteln abverlangen. so gesehen muss man ohnehin froh sein, wenn dort nicht "erfahrene" cobol od. fortan programmierer gesucht werden. ;)

in wirklichkeit beschäftigt mich aber vielmehr die frage, welche betroffenen anwendungen ich od. gleichgesinnte tatsächlich installiert haben könnte?

da fällt es dann schon auf, wie wenig von den großen java-versprechungen in der praxis tatsächlich übrig gebieben ist.

wie gesagt, am desktop betrifft es bei mir fast ausschließlich mediathekview -- wo ich mir ohnehin bei jedem start des programms wünsche, das sich endlich jemand findet, um einen eleganten, schlanken, hübscheren und besser bedienbaren ersatz dafür schaffen.

auf den servern schaut's natürlich ein bisserl anders aus. da gibt's tatsächlich so sachen wie keycloack (übrigens nicht betroffen!), für die ich kaum eine ersatz nennen könnte, der sympatischere mittel verwendet.

und auch mit Jitsi und BigBlueButton, die beide leider in diesem fall auch tatsächlich betroffen sind, ging's mir immer ähnlich. mit viel bauchweh, da einem zwar die art der umsetzung überhaupt nicht gefällt, hat man's doch verwendet od. weiterempfohlen, weil es halt keine guten alternativen dazu gibt/gab.

trotzdem -- es sind doch eher nur ein paar ganz wenige ausnahmen. dinge, die entweder eine sehr lange vorgeschichte haben oder als eigenwillige überbleibsel aus dieser anderen kommerziellen welt angeschwemmt worden sind.

dort, wo es sich programmierer frei aussuchen können, mit welchen mitteln sie arbeiten bzw. wie sie ihr ziel möglichst sauber und befriedigend erreichen können, dürfte heute wohl kaum noch jemand aus freien stücken zu java greifen -- o.k., es gibt sicher auch noch eingefleischte delphi/lazarus od. Tcl/Tk fans... -- am ehesten dürfte es noch im android umfeld eine reale berechtigung dafür geben, wo nun zwar kotlin auch bereits die nachfoge angetreten hat, aber eben leider auch keine tiefgreifende verbesserung mit sich bringt...

so gesehen verfolge ich das ganze geschichte wirklich eher als zaungast, weil es jdie server, für die ich mich verantwortlich fühle, und den großteil der von mir bevorzugten software diesmal nicht betrifft -- obwohl das natürlich eher ein zufall ist und sicher auch ganz gegenteilig kommen hätte können.

[cantsin]

ich hab damit z.b. vor mittlerweile 25 jahren für eine komponistin eine art piano-roll-interface entwickelt, wo mehrere "dirigenten" an verschiedenen orten auf der welt nach hart einkodierten spielregeln während der aufführung live in eine gemeinsam gespielte partitur aus dem browser heraus eingreifen konnten (http://kunstradio.at/RIV_BRI/PROJECTS/s ... /fish.html -- "...REQUIRES NETSCAPE NAVIGATOR 2.0" ;)). das war schon toll!

Lustigerweise habe ich mit Elisabeth Schimana auch schon zusammengearbeitet, allerdings als Schreiber...

[Frank Glencairn]

log4j steckt auch in Davinci Resolve (in der Photon-Bibliothek)..

[roki100]

Siehe auch: https://github.com/NCSC-NL/log4shell/bl ... /README.md

[cantsin]

"Neue Probleme - Log4j-Patch genügt nicht"

https://www.heise.de/news/Neue-Probleme ... 95343.html

[mash_gh4]

log4j steckt auch in Davinci Resolve (in der Photon-Bibliothek)..

wenn man resolve von der kommandozeile startet, um an hand der ausgaben im terminal irgendwelchen fehlern nachzugehen, entgehet es einem kaum, das log4j logging bzw. debugging mechanismen im resolve genutzt werden. allerdings muss das nicht gleich bedeuten, dass das betreffende programm von der aktuellen problematik betroffen ist, da es ja ableger des programms in anderen programmiersprachen gibt, die nach außen hin sehr ähnlich wirken, aber diese sichheitslücke nicht aufweisen.

es ist aber natürlich fein, dass BMD in diesem fall rasch regiert und ein update bereitstellt.

trotzdem bin ich davon überzeugt, dass resolve, wie auch viel andere ähnlich monströs ausufernde closed source anwendungen, derart viel völlig veralteten problematischen code mitschleppen und aus kompatibilitätsgründen auf den geräten der endanwender installieren -- libraries, die in der systemweiten installation aller aktuellen linux-, windows- od. mac os ausgaben längst in aktuelleren und in vielerlei hinsicht gefixten varianten verfügbar wären --, dass dieses konkrete problem eher nur als tropfen auf dem heißen stein zu verstehen ist.

mit dem konkreten update befriedigt man also zwar die aufgeschreckte öffentlichkeit, aber an all den gravierenden problemen, die unter der oberfläche weiterhin verborgen bleiben und der ganz grundsätzlichen damit verbundenen sicherheitsproblematik ändert das aber natürlich leider gar nichts. :(

[mash_gh4]

"Neue Probleme - Log4j-Patch genügt nicht"

https://www.heise.de/news/Neue-Probleme ... 95343.html

ja -- 2.16 wird natürlich in den großen linux-distributionen ohnehin seit gestern ausgerollt, womit man zumindest den größten teil der betroffenen server-anwendungen ohne großen aufwand absichern kann.

problematischer ist natürlich die sache mit dem closed source anwendungen, wo die hersteller meist mehr interesse an der werbewirksamkeit entsprechender updates haben als das problem tatsächlich sauber zu fixen. dort können sich derartige stufenweise verbesserungen leider oft nicht bis zu einem befriediegenden abschluss durchsetzten, weil es ja peinlich wirken könnte, die benutzer ein weiteres mal zu einem umständlichen händischen update zu bewegen...

[TheBubble]

wenn ich mich hin und wieder nach arbeit umsehe, fällt mir natürlich schon auf, wie gefragt java in der realen wirtschaftswelt da draußen noch immer ist. damit verhält es sich offenbar ganz ählich wie der videotechnik die in den rundfunkanstalten genutzt wird. auch dort hält man qualitätsstandards und auslieferungsformaten fest, die heute jedem einigermaßen engagierterter amateur höchstens ein kopfschütteln abverlangen.

Das ist doch überhaupt nicht vergleichbar. Abgesehen davon: Java heute != Java der 90er.

so gesehen muss man ohnehin froh sein, wenn dort nicht "erfahrene" cobol od. fortan programmierer gesucht werden. ;)

Werden wohl tatsächlich gesucht und angeblich gut bezahlt.

da fällt es dann schon auf, wie wenig von den großen java-versprechungen in der praxis tatsächlich übrig gebieben ist.

Wenn man Marketing und Applets weg lässt, was fehlt denn? Java ist mit das Portabelste, was es im Augenblick gibt. Die ganzen interpretierten Sprachen mit ihren Defiziten kann man wohl kaum einen vergleichbaren Ersatz nennen, auch wenn sie - wenn nicht spezielle Erweiterungen genutzt werden - natürlich portabel sind.

dort, wo es sich programmierer frei aussuchen können, mit welchen mitteln sie arbeiten bzw. wie sie ihr ziel möglichst sauber und befriedigend erreichen können, dürfte heute wohl kaum noch jemand aus freien stücken zu java greifen

Oh doch. Und es gibt Gründe.

Android: Java (die Sprache, nicht die gleiche Laufzeitumgebung). Ja, es gibt noch Kotlin (auf der gleichen Runtime), ein paar Dinge sprechen jedoch noch immer dagegen: Wie lange wird die Sprache weiterentwickelt? Wird sie vielleicht nur wegen dem Streit um Java so gepushed, um rasch eine Alternative zu haben? Der Hauptsponsor hat schon so manches große Projekt überraschend eingestellt. Abgesehen davon: Eine neue Sprache bedeutet auch (viel) Zeit investieren, neue Fehler machen, weniger Erfahrung nutzen können (=zunächst geringere Produktivität). Java unter Android nutzen heißt auch Teile des gleichen Codes auf dem Server nutzen zu können, wieder ein Produktivitätsgewinn und abgesenktes Fehlerpotential.

Prototyping: Java ist von der Syntax noch nah genug an C/C++, um einen Prototypen später einfacher portieren zu können, da man eine ähnliche Vorlage hat. Versuch das mal mit PHP.

Portable spezielle Desktop-/Server-Anwendungen: Die Spezialsoftware soll unter Windows und Linux laufen. Klar, beides muss getestet werden, aber es sollte funktionieren. Wenn man keinen direkten Zugriff auf die OS APIs braucht und höchste Performance keine Rolle spielt, ist Java (oder zum Teil auch .NET) eine akzeptable Wahl.

Was sollen denn die Alternativen für die Bereiche Mobile, Server und Desktop sein?

PHP? Python? Sprachen, die einen freundlichen Einstieg ermöglichen, Fehler jedoch erst zur Laufzeit melden und praktisch keine Typensicherheit haben? Gleich C/C++ nehmen? Immer neu kompilieren, nicht triviale Programme für jedes OS anpassen (oder teils riesige abstrahierende Bibliotheken/Umgebungen wie Qt verwenden), im Grunde keine Festlegungen, was z.B. ein "int", "short", usw. genau sein soll? Das volle Potential für Speicherlecks, Speicherfehlern und Buffer-Overflows endgültig auf die Server holen, deren Software (Webanwendung, Webservice, ...) viel zu oft von Leuten ohne viel Ahnung und Übersicht geschrieben wird? Klar, viele davon sind selbst mit Java überfordert, darum benutzen sie es auch nicht. Wenn Du aber all den vielen Nur-Java-Entwicklern jetzt C++ verordnest: Viel Vergnügen! :-D

Kommerzielle Software: Ein Alleinstellungsmerkmal, direkt samt Quelltext auch zum Mitbewerber geliefert, ist für viele ein No-Go. Selbst gegenüber Java und .NET gab es lange eine gewisse Abneigung, da der Bytecode viel leichter als ein C++-Programm rückübersetzt werden kann und erhebliche Rückschlüsse erlaubt. Aufgrund diese Ängste gibt es die ganzen Obfuscator-Werkzeuge, um Bezeichner unleserlich zu machen.

Es ist nicht so einfach. Man muss Java nicht mögen, muss jedoch auch den Nutzen sehen und verstehen, warum es so beliebt ist.

Ich kann Java für Prototypen/Entwürfe/Spezialprogramme gut leiden. Die Einschränkungen erzwingen die Konzentration auf das Wesentliche, man kümmert sich zunächst nur um die Sache/das Ergebnis. Da Java beliebt ist, gibt es viele Bibliotheken, die helfen, die benötigten (Test-)Daten zu importieren oder die ein oder andere benötigte Fleißarbeit abnehmen. Aufgrund einer zu C++ ähnlichen Syntax, kann man bei Bedarf leichter portieren, im Gegensatz zu Matlab/Python/usw. Beizeichner können im Vergleich zu C++ leicht umbenannt werden, die Java-IDE prüft auf Konflikte. Bei C++ ist das für die Tools viel schwieriger. Gleiches gilt für weitere Refactoring-Werkzeuge. Auch wird es kompiliert und hat gegenüber den genannten interpretierten Sprachen Typensicherheit.

[roki100]

Neue Probleme - Log4j-Patch genügt nicht
Version 2.15.0 von Log4j sollte die Log4Shell-Sicherheitslücke schließen. Das reichte jedoch nicht. Log4j 2.16.0 behebt nun noch eine weitere Schwachstelle.... https://www.heise.de/news/Neue-Probleme ... 95343.html