Aversion gegen Java
-
Ethon_ schrieb:
Hier geht es wohl um Fehler in diversen Implementierungen.
Wenn ich jetzt eine SSL-Library in C++ entwickle, Bugs einbaue, dann ist das nicht wirklich ein C++ Problem.Das ist ein Strohmann von dir!
Niemand behauptet dass der Java Sprachstandard an sich irgendwie hinsichtlich Security krass kaputt wäre. Bzw. zumindest ich behaupte das nicht. Und ich habe auch bei den anderen Java-kritischen Stimmen hier nicht den Eindruch dass die das tun. Nur ist die Erkenntnis dass es da kein bzw. kein krasses Problem gibt nicht viel Wert. Umgekehrt, also wenn der Sprachstandard an sich schon kaputt wäre, wäre es natürlich fatal. Also die Frage ist schon interessant -- nur halt lange nicht hinreichend.
Und strenggenommen gilt das genau so für C++ und so ziemlich jede andere Sprache überhaupt. Da gibt es auch kein Problem mit dem Sprachstandard an sich. Wenn man korrekte und sichere C++ Programme schreibt, dann funktionieren die auch korrekt und sicher.
Wenn ich behaupte würde dass Java nicht sicher ist (was ich hier gar nicht getan habe, aber das Thema hatten wir ja schon)... dann würde ich damit also klarerweise die Implementierung meinen. Und da ist es bei Java nunmal einfach so, dass grösstenteils nur eine Implementierung im "Enterprise-Segment" verwendet wird, und das ist halt einfach die von Oracle.
----
Ja, in C++ kann man sich leichter mit *eigenem* Code so ins Knie schiessen dass dabei ein sicherheitskritischer Bug entsteht. In Java ist das schwieriger.
Dafür hast du in Java eine Implementierung die fast überall verwendet wird, und die sehr sehr sehr viel mehr bereit stellt als die Standard-Library von C++. Und was im JDK schon drinnen ist, dafür nimmt man auch nicht ohne Not externe Libraries. Dadurch hast du einerseits eine viel breitere Angriffsfläche.
D.h. bei Java kannst du dir wesentlich einfacher einen kritischen Bug durch Fehler in der Implementierung eintreten. Und damit ist die Frage ob die Implementierung sicher ist oder nicht sehr relevant.
-
hustbaer schrieb:
Ethon_ schrieb:
Hat aber wenig mit der JVM, dem JDK und der sonstigen Java-Infrastruktur zu tun.
Das hat alles mit der JVM und dem JDK zu tun, da ein grosser Teil der Exploits auf Bugs in der JVM und/oder dem JDK basieren. Oder meinst du dass das Browser-Plugin ein grundlegend anderes, schlechteres JDK verwendet als normale Anwendungen? Oder vielleicht dass die ganzen Bugs alle nur im Browser-Plugin-spezifischen Code zu Hause waren? Das ist nämlich nicht der Fall, ein grosser Teil sind einfach ganz normale Bugs im JDK.
Ich behaupte einfach mal, dass das alles nur für das Browser Plugin relevant ist. Nur dort gibt es überhaupt das Sicherheitskonzept einer Sandbox aus der ein Javaprogramm nicht ausbrechen darf, deshalb kann es auch nur dort Sicherheitslücken geben. In anderen Zusammenhängen dürfen Javaprogramme sowieso alles machen. ...wie C++ Programme auch.
-
Dann behaupte ich mal dass du damit falsch liegst. Klick mal auf
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19116/Oracle-JDK.html
und lies dir die Beschreibung von ein paar der vielen "10er" Bugs durch.
Da geht es nicht um Sandboxing Verletzungen. Da geht es um schlimme Bugs im JDK/JRE. Remote Code Execution und so, echt krasser Scheiss.Guck dir z.B. mal diesen Bug an:
https://www.cvedetails.com/cve/CVE-2013-5907/
OK, da steht dass Oracle die Vermutung nicht bestätigt hat, aber das tut Oracle sowieso nie. Worum es mir geht ist das Verständnis was mit "vectors via X" gemeint sein kann. Kann also heissen dass es reicht wenn dein Programm ein prepariertes Datenfile lädt und dem JDK zum Dekodieren füttert.Es betrifft also definitiv nicht nur das Browser Plugin. Es betrifft viel viel mehr. Wird bloss von vielen totgeschwiegen oder falsch dargestellt. Vermutlich weil Java auf dem (privaten) Desktop nicht mehr wirklich relevant ist, weil so verflixt wenige "nicht enterprisige" Anwendungen in Java geschrieben sind.
----
Das Browser Plugin ist nur deswegen besonders in Verruf, weil es uns als sicher verkauft wurde - und in Wirklichkeit leider überhaupt nicht sicher ist. Und weil es, wenn man seinen Browser auf "ausführen ohne nachfragen" eingestellt hat, den Brain.exe Virenscanner komplett umgeht - weil man ja nichtmal mitbekommt dass man ein Java-Applet startet wenn man auf einen Link auf ne infizierte Seite klickt.
-
Bin ich blind oder steht da nie, welche API betroffen ist?
-
Das steht da nie. Weil Oracle zu feige ist.
Und nu? Ist deswegen jetzt alles nur erfunden weil das da nicht steht?ps: Wobei grob um was es geht steht da schon. Das ganze "vector related to X" halt.
-
Naja, ist von daher interessant, dass ich mir im Vergleich mal Apache angeschaut habe. Und da sind einige "kritische" Bugs in äußerst selten genutzten und unkritischen Komponenten gelistet.
-
Wenn man korrekte und sichere C++ Programme schreibt, dann funktionieren die auch korrekt und sicher.
Wer schreibt denn bitte korrekte und sichere C++-Programme? Das dürfte doch wohl die absolute Minderheit sein.
-
hustbaer schrieb:
Ich erkenne nur dein Argument nicht an, weil das Argument halt Blödsinn ist.
DAS ist natürlich ein Argument
Nur Sarkasmus
Brauchst nicht darauf anworten, ich geb dir ansonsten völlig Recht.
-
LOLometer schrieb:
Wenn man korrekte und sichere C++ Programme schreibt, dann funktionieren die auch korrekt und sicher.
Wer schreibt denn bitte korrekte und sichere C++-Programme? Das dürfte doch wohl die absolute Minderheit sein.
Vor allem kann niemand beweisen, dass ein Programm sicher und korrekt ist, höchstens das Gegenteil.
Naja, außer man taucht in die Tiefen der puren, funktionalen Sprachen ab. Aber "Unsicherheit" ist in erster Linie bei Netzwerkprogrammen relevant, da wird es schwierig, Korrektheit zu beweisen.
-
Naja doch, beweisen kann man das schon meistens. Ist nur oft sehr mühsam.
-
hustbaer schrieb:
Das steht da nie. Weil Oracle zu feige ist.
Ich glaub eher, Oracle interessiert das gar nicht.
-
Verstehe nicht - wie soll sie das nicht interessieren? Die fixen die Fehler ja, also müssen sie sich "dafür interessieren", und dann auch wissen was genau betroffen ist/war.
Oder meinst du dass sie einfach nur für den letzten Schritt das auch in der Fehlerdatenbank einzutragen zu faul sind?
-
hustbaer schrieb:
Verstehe nicht - wie soll sie das nicht interessieren? Die fixen die Fehler ja, also müssen sie sich "dafür interessieren", und dann auch wissen was genau betroffen ist/war.
Oder meinst du dass sie einfach nur für den letzten Schritt das auch in der Fehlerdatenbank einzutragen zu faul sind?So wie sich Oracle seit einiger Zeit verhält....Ich denke Java ist für die nur ein notwendiges übel.
-
Und das ist auch gut so.
-
Wutz schrieb:
Und das ist auch gut so.
Weil du Java nicht magst oder weil du es Oracle ned gönnst?
-
raptor49 schrieb:
Wutz schrieb:
Und das ist auch gut so.
Weil du Java nicht magst oder weil du es Oracle ned gönnst?
Weil er stänkern will.
-
Java mag Schwächen haben (wie jede andere Sprache auch), aber die besten IDEs gibt es für Java (IntelliJ), was das Arbeiten damit wieder angenehm und extrem produktiv macht. Auch die Bibliotheks-Vielfalt sei zu erwähnen.
-
ShadowClone schrieb:
Java mag Schwächen haben (wie jede andere Sprache auch), aber die besten IDEs gibt es für Java (IntelliJ), was das Arbeiten damit wieder angenehm und extrem produktiv macht. Auch die Bibliotheks-Vielfalt sei zu erwähnen.
Ja, IntelliJ ist super. Aber inzwischen unglaublich speicherhungrig geworden.
-
ShadowClone schrieb:
Java mag Schwächen haben (wie jede andere Sprache auch), aber die besten IDEs gibt es für Java (IntelliJ), was das Arbeiten damit wieder angenehm und extrem produktiv macht. Auch die Bibliotheks-Vielfalt sei zu erwähnen.
Ned hauen, aber soooo toll finde ich die jetzt auch ned.
-
Leute nehmt doch einfach das OS, die Programmiersprache und die Programme die euch gefallen und mit denen ihr am besten vom Start zum Ziel kommt. Mir als Benutzer ist es doch scheißegal was für eine Firma dahintersteht, ob das Produkt OpenSource oder von Gott persönlich gesegnet wurde. Wenn das Produkt zu mir passt, dann wird es benutzt, so einfach ist das. Mich würde nie interessieren wie andere meine Werkzeuge finden, denn ich muss doch damit arbeiten.
