Geschwindigkeit vs. Sicherheit
-
finix schrieb:
Gregor schrieb:
Ich wollte mit dem Absatz oben sagen, dass Sicherheitslücken in der JVM und die Sicherheit von Javaprogrammen zwei unterschiedliche Sachen sind, die auch nicht zusammenhängen. Das eine hat mit bösartigen Programmen zu tun, das andere hat mit Sicherheitslücken in Programmen zu tun. Durch die Sicherheitslücken in der JVM sind NICHT automatisch auch Sicherheitslücken in Javaprogrammen.
Ja, stimmt, nur wenn sie von der JVM ausgeführt werden
Nein, Du irrst Dich. Ich wollte eben genau darauf hinweisen, dass das nicht so ist. Als "externer Angreifer" kommt man nicht an die JVM bzw. deren Sicherheitslücken heran, weil man keinen Code in die laufende Javaanwendung einschleusen kann. Und in den Javaanwendungen können zumindest keine Sicherheitslücken auftreten, die auf Buffer overruns oder so basieren.
Zeig mir doch mal eine Meldung, dass in einem Javaprogramm eine Sicherheitslücke aufgetreten ist. ...die JVM ist kein Javaprogramm.
-
finix schrieb:
Gregor schrieb:
IMHO wäre der erste Schritt zur Besserung, die Schwächen überhaupt zu erkennen. Aber aus meiner Sicht ist die C++-Welt immer noch in einer Leugnungsphase. Wirklich schade.
Dafür ist Java direkt in diese Leugnungsphase gestartet
Nein, Du irrst Dich. Die Javawelt hatte zum Beispiel mal erkannt, dass Java ein Performanceproblem hatte. Daran wurde dann gearbeitet. Inzwischen ist es vielleicht noch nicht komplett behoben, aber es hat sich um Größenordnungen verringert. Bei Java wird also an den Schwächen gearbeitet.
-
Gregor schrieb:
rüdiger schrieb:
C++ kann man so programmieren, das Index-Probleme nicht erlaubt sind
Wobei das irgendwie zu wenig Leute machen, denn Sicherheitslücken in C++ Programmen sind real. Und das spricht dafür, dass es gut ist, einen entsprechenden Zwang für solche Index-Checks von der Sprache her vorzugeben.
nöö.
das spricht nur dafür, daß projekte, wo der indexzwang sinnvoll ist, java (oder andere sprachen ohne indexfehlermöglichkeit) nehmen. ups, indexfehlermöglichkeit gibts ja immer. nur die behandlung ist anders. wenn ich den java-mailserver bei jedem indexfehler per exception kille und er erst 5 minuten später reinkarniert, ist das auch eine sicherheitslücke. wirksame dos-attacke mit 144-er modem. man könnte die mitarbeiter wirksam zwingen, in c++ keine rohen arrays zu benutzen, sondern nur welche mit indexgrenzencheck.
aber für mich ist das ein historisches problem. in c war das üblich.
nett wäre eine änderung des standards, daß man rohe arrays und dergleichen mit einer warnung versieht, außer, der programmierer scheibtchar i[39];//i_know_what_i_do
als kommentar dahinter. das kann ich als projektleiter dann leicht automatisiert suchen und gegebenenfalls gestatten und die datei nach gestattung mit md5 versiegeln.
-
Gregor schrieb:
Bei Java wird also an den Schwächen gearbeitet.
Das ist doch bei C++ auch nicht anders. Siehe die TRs und den neuen Standard.
-
Jester schrieb:
Gregor schrieb:
Bei Java wird also an den Schwächen gearbeitet.
Das ist doch bei C++ auch nicht anders. Siehe die TRs und den neuen Standard.
Ja, in der Tat. Ich erhoffe mir von dem nächsten C++ Standard einiges. Hoffentlich kommt der bald. ...wobei ich die Entwicklung von C++ insgesamt für zu langsam halte, aber das ist wohl eine subjektive Meinung. Werden im neuen Standard solche Index-Checks angegangen? Was ist momentan das angepeilte Datum für den neuen Standard?
-
finix schrieb:
In Bezug auf die Bibliotheken: natürlich braucht man die, aber das ist bei Java nicht anders. Bei Java ist schlicht die Standard-Bibliothek umfangreicher (und dass die nicht unbedingt immer perfekt ist sieht man allein an der Existenz von Swing und insbesondere SWT).
Swing IST Teil der Standard-Bibliothek!
-
byto schrieb:
finix schrieb:
In Bezug auf die Bibliotheken: natürlich braucht man die, aber das ist bei Java nicht anders. Bei Java ist schlicht die Standard-Bibliothek umfangreicher (und dass die nicht unbedingt immer perfekt ist sieht man allein an der Existenz von Swing und insbesondere SWT).
Swing IST Teil der Standard-Bibliothek!
Und SWT ist IMHO übrigens eine Modeerscheinung, die in ein paar Jahren wieder weg sein wird. Swing ist einfach viel angenehmer zu nutzen und die Gründe, die für SWT sprechen, verschwinden mit der Zeit. IMHO sind sie heute schon weg.
-
Gregor schrieb:
wobei ich die Entwicklung von C++ insgesamt für zu langsam halte, aber das ist wohl eine subjektive Meinung.
die teile ich.
Werden im neuen Standard solche Index-Checks angegangen?
wäre ganz untypisch. man kann sich ja indexgrenzenprüfende klassen bauen.
afair gab es irgendwo einen vorschlag, daß beim vector der op[] prüfen soll, weil eh kein arsch at() verwendet. weiß aber nicht mehr, ob der ernst gemeint war.
korrekt wäre, daß at() weiterhin ne exception wirft und [] ne assertion. also abschaltbar für den release-code bei []. und das ist eigentlich allein sache der bibliothekenbauer.
-
Ich bin zuversichtlich, daß so ein assert bereits heute in meiner stdlib-Implementierung drinsteht.
-
byto schrieb:
finix schrieb:
In Bezug auf die Bibliotheken: natürlich braucht man die, aber das ist bei Java nicht anders. Bei Java ist schlicht die Standard-Bibliothek umfangreicher (und dass die nicht unbedingt immer perfekt ist sieht man allein an der Existenz von Swing und insbesondere SWT).
Swing IST Teil der Standard-Bibliothek!
Da ging's um Gregor's Argument dass bei Java gleich alles dabei ist, und man nicht auf Bibliotheken von Dritten angewiesen ist.
/editHm. Da demonstrierst du natürlich ein sehr gutes Argument. Aber ich denke das Sicherheitsmodell von Java geht immer noch nicht weit genug für Leute die noch nicht einmal einen einzigen, unkomplizierten Satz korrekt lesen können.
-
@finix: Wird er durch solche Aussagen eigentlich länger?
MfG SideWinder
-
finix schrieb:
für Leute die noch nicht einmal einen einzigen, unkomplizierten Satz korrekt lesen können.
Und als nächstes Argument kommt dann "Der ist nicht korrekt, denn Du hast da nen Rechtschreibfehler.". Toll. Ich glaube, ganz so tief müssen wir mit dem Niveau in diesem Thread nicht unbedingt gehen. Im Übrigen habe ich auch nicht verstanden, worauf Du mit Deinem Beitrag da eigentlich hinaus wolltest. Vielleicht stellst Du es einfach klar, dann redet man nicht mehr aneinander vorbei.
-
SideWinder schrieb:
@finix: Wird er durch solche Aussagen eigentlich länger?
Ja, und wie. Solltest du auch mal probieren, dann ziehst du vielleicht nicht immer den kürzeren...
-
Gregor schrieb:
finix schrieb:
für Leute die noch nicht einmal einen einzigen, unkomplizierten Satz korrekt lesen können.
Und als nächstes Argument kommt dann "Der ist nicht korrekt, denn Du hast da nen Rechtschreibfehler.". Toll. Ich glaube, ganz so tief müssen wir mit dem Niveau in diesem Thread nicht unbedingt gehen. Im Übrigen habe ich auch nicht verstanden, worauf Du mit Deinem Beitrag da eigentlich hinaus wolltest. Vielleicht stellst Du es einfach klar, dann redet man nicht mehr aneinander vorbei.
Es ging einfach um die "Bibliotheken von Dritten" die man verwendet. Swing war einfach nur ein Beispiel dafür dass die Standard-Bibliotheken auch nicht immer das wahre sind - d.h. wäre AWT so toll gewesen gäbe's kein Swing, wäre Swing problemfrei gäbe es kein SWT.
-
finix schrieb:
Es ging einfach um die "Bibliotheken von Dritten" die man verwendet. Swing war einfach nur ein Beispiel dafür dass die Standard-Bibliotheken auch nicht immer das wahre sind - d.h. wäre AWT so toll gewesen gäbe's kein Swing, wäre Swing problemfrei gäbe es kein SWT.
Ach so. Ja, ok. Natürlich ist die Standardbibliothek von Java nicht perfekt und sie entwickelt sich auch weiter. Es werden Dinge deprecated usw.. Ob AWT und Swing jetzt die besten Beispiele dafür sind, wage ich zu bezweifeln: Die decken eigentlich unterschiedliche Bedürfnisse ab und das AWT ist ja auch nicht deprecated oder so. SWT halte ich persönlich für eine Modeerscheinung, die bald wieder verschwinden wird, aber das habe ich ja schon gesagt.
-
Gregor schrieb:
Ach so. Ja, ok. Natürlich ist die Standardbibliothek von Java nicht perfekt und sie entwickelt sich auch weiter. Es werden Dinge deprecated usw.. Ob AWT und Swing jetzt die besten Beispiele dafür sind, wage ich zu bezweifeln: Die decken eigentlich unterschiedliche Bedürfnisse ab und das AWT ist ja auch nicht deprecated oder so. SWT halte ich persönlich für eine Modeerscheinung, die bald wieder verschwinden wird, aber das habe ich ja schon gesagt.
Wo sind denn die Unterschiede zwischen AWT und Swing, abgesehen davon dass beides GUI-Toolkits sind?
-
Gregor schrieb:
Java vs. Groovy? Soetwas habe ich noch nicht gesehen. Wo gibt es denn solche Diskussionen?
Damit wollte ich eigentlich auf alle Diskussionen abzielen, die sich beispielsweise um Closures in Java drehen.
-
Gregor schrieb:
finix schrieb:
Genau, ebenso kreativ wie zu übersehen das C/C++ an sich auch plattformunabhängig sind und dass es für den überwiegenden Teil der Aufgaben die man im Normalfall so bewältigen möchte plattformunabhängige Bibliotheken gibt.
Ich habe einmal eine Erfahrung mit Qt gemacht und das reicht mir praktisch schon, was diese plattformübergreifenden Bibliotheken betrifft: Die sind auch nicht so perfekt, wie man es vielleicht annehmen sollte. Gerade wenn man irgendwelche nativen GUI-Komponenten nutzt, die zum Beispiel auf anderen Plattformen nicht vorhanden sind. Resultat: Das Qt-Programm hat unter Windows funktioniert, unter Linux nicht. ...ich muss dazu sagen, dass das Programm nicht von mir war.
LOL
Natürlich ist eine plattformübergreifende nicht plattformübergreifend, wenn man sie mit Systemabhängigen-Code mischt. Man kann ja auch in Java System abhängigen Code schreiben (da reichen ja nur ein paar Pfadangaben oder einige Dinge bei Threads) und der ist dann zwar immer noch nicht Plattformunabhängig, aber er ist dann sogar davon Abhängig auf welcher Plattform die Plattform läuft.
Damit haben wir aber immer noch nicht gezeigt, warum wir uns ausgerechnet Java antun sollten, um sichere Programme zu schreiben.
-
rüdiger schrieb:
Damit haben wir aber immer noch nicht gezeigt, warum wir uns ausgerechnet Java antun sollten, um sichere Programme zu schreiben.
Gregor schrieb:
Zeig mir doch mal eine Meldung, dass in einem Javaprogramm eine Sicherheitslücke aufgetreten ist. ...die JVM ist kein Javaprogramm.
Du bist dran.
-
finix schrieb:
Wo sind denn die Unterschiede zwischen AWT und Swing, abgesehen davon dass beides GUI-Toolkits sind?
Das ist ja auch die Gemeinsamkeit.
AWT nutzt native Komponenten, Swing zeichnet selber. Aus diesem Grund hast Du bei AWT eine geringere Auswahl an Komponenten, dafür entspricht das L&F aber eher dem L&F, das auf der jeweiligen Plattform üblich ist. Bei Swing geht man genau andersherum an die Sache heran. Wenn man davon absieht, dass man da pluggable L&Fs verwenden kann, die das native L&F nachahmen, ist das Ziel eigentlich eher, auf allen Plattformen das gleiche L&F anzubieten. Insofern steht das SWT eigentlich auch eher in Konkurrenz zum AWT und nicht zu Swing.
Die Frage ist halt, welches Verhalten man für seine Anwendung lieber hätte. Ich halte den Ansatz von Swing für besser.