Geschwindigkeit vs. Sicherheit
-
TactX schrieb:
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
Musst aber ein gut ausgerüstetes handy haben. Wenn jetzt Doom 3 auf meinem Rechner nicht läuft heißt das also, dass bei mir nix was in C/C++ geschrieben wurde läuft
-
TactX schrieb:
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
Du hast da halt bestimmte Begriffsvorstellungen und andere Leute haben andere Begriffsvorstellungen. "Plattformunabhängigkeit" sehe ich zum Beispiel immer als Gegensatz zur "Portierbarkeit". Javaprogramme werden nicht auf andere Plattformen portiert. Wenn es da eine entsprechende JRE gibt, dann laufen sie da halt. Ich kann als Nutzer das Javaprogramm auf die neue Plattform mitnehmen. Beim Portieren spielt hingegen der Entwickler eine deutlich wichtigere Rolle.
-
Gregor schrieb:
Es mag auch Probleme geben, Javaprogramme für verschiedene Plattformen verfügbar zu machen. Diese sind aber viel geringer als die Probleme, die sich einem da beispielsweise mit C++ stellen. ...solange eine JVM für die entsprechenden Plattformen existiert.
Inwiefern sind denn die Probleme "viel geringer"?
-
Gregor schrieb:
TactX schrieb:
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
Du hast da halt bestimmte Begriffsvorstellungen und andere Leute haben andere Begriffsvorstellungen. "Plattformunabhängigkeit" sehe ich zum Beispiel immer als Gegensatz zur "Portierbarkeit". Javaprogramme werden nicht auf andere Plattformen portiert. Wenn es da eine entsprechende JRE gibt, dann laufen sie da halt. Ich kann als Nutzer das Javaprogramm auf die neue Plattform mitnehmen. Beim Portieren spielt hingegen der Entwickler eine deutlich wichtigere Rolle.
Deswegenn ist Java selbst auch ne Platform *g*
-
finix schrieb:
Inwiefern sind denn die Probleme "viel geringer"?
Oh, lass uns doch mal gucken, was da auf den C++-Entwickler zukommt:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1014628.html
Der Rest der Arbeit läuft so ähnlich ab, wie als wenn man eine Library wrappt – denn etwas anderes tut man ja nicht. Das Schöne daran ist, dass man gleich ein OO-Interface über diese Funktionen legen kann. Da dies aber viel Arbeit ist, ist es oft sinnvoll etwas nur "on demand" zu wrappen (das heißt nur dann, wenn man es wirklich braucht). Stlsoft stellt dafür eine gute Anlaufstelle dar.
Wenn man für zwei oder mehr Plattformen entwickelt, wird man an verschiedenen Stellen ein Problem verschieden lösen müssen, auch wenn die Bibliotheken alle plattformunabhängig sind (wir leben ja leider nicht in einer perfekten Welt). Dann ist es wichtig, den Code nicht durch viele #ifdefs unleserlich zu machen. Eine gute Lösung hierbei ist es, für jede Plattform eine eigene Source Datei anzulegen. Dadurch hat man zwar mehr Code zu warten und man muss etwaige Bugfixes auf andere Plattformen übertragen, aber man erkauft sich dafür leichter zu lesenden Code. Denn bei vielen #ifdefs kann man leicht den Überblick verlieren, und was wohl am schlimmsten ist: auf eine neue Plattform Portieren kann unnötig kompliziert werden (weil wir schon wieder an 100.000 einzelnen Stellen den Code ändern müssen).
Um die Transparenz zu wahren, kann man Proxy-Dateien verwenden. Man erstellt pro Plattform einen eigenen Verzeichnisbaum (zum Beispiel code/programm/win32, code/programm/linux, ...) und legt an der zentralen Stelle (bei uns zum Beispiel code/programm) eine Proxy-Datei ab. Diese inkludiert lediglich die richtige Plattformdatei. Dank des Präprozessors kann man hier recht simpel #ifdefs machen, um die richtige Plattform auszuwählen. Der Clientcode bekommt davon nichts mit.
...usw.
Bei Java sähe das so aus: "Du musst darauf achten, dass Du nicht künstlich irgendwelche Plattformabhängigkeiten in den Code einbaust."
Das Problem dreht sich also komplett um.
-
TactX schrieb:
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
Wenn Du wenigstens wissen würdest, wie Eclipse - im speziellen SWT - funktioniert, dann hättest Du damit sogar eine ansatzweise sinnvolle Kritik in Sachen Plattformunabhängigkeit anbringen können. Aber so wars ja wohl ein Schuss in den Ofen.
-
byto schrieb:
TactX schrieb:
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
Wenn Du wenigstens wissen würdest, wie Eclipse - im speziellen SWT - funktioniert, dann hättest Du damit sogar eine ansatzweise sinnvolle Kritik in Sachen Plattformunabhängigkeit anbringen können. Aber so wars ja wohl ein Schuss in den Ofen.
Ich weiss, dass ich Eclipse nicht auf meinem Handy starten kann. Warum das so ist ist doch total nebensächlich.
-
Gregor schrieb:
finix schrieb:
Inwiefern sind denn die Probleme "viel geringer"?
Oh, lass uns doch mal gucken, was da auf den C++-Entwickler zukommt:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1014628.html
[SNIP]
...usw.
Bei Java sähe das so aus: "Du musst darauf achten, dass Du nicht künstlich irgendwelche Plattformabhängigkeiten in den Code einbaust."
Das Problem dreht sich also komplett um.
Um. Ja.
Soll ich jetzt die JNI-Dokumentation zitieren um zu zeigen was auf den Java-Entwickler so alles zukommt? ( )Was meinst du eigentlich mit diesem ominösen "usw"? Was, außer dem wrappen von plattformspezifischem Code, wenn überhaupt (Stichwort: Libraries), kommt denn noch alles auf den C++ Entwickler zu?
-
finix schrieb:
Um. Ja.
Soll ich jetzt die JNI-Dokumentation zitieren um zu zeigen was auf den Java-Entwickler so alles zukommt? ( )Oh man. Du willst mir bei einem "Java ist plattformunabhängig" vorhalten, dass man auch mit Java fremden Code nutzen kann, der in anderen Programmiersprachen geschrieben ist? Das ist echt kreativ!
finix schrieb:
Was meinst du eigentlich mit diesem ominösen "usw"? Was, außer dem wrappen von plattformspezifischem Code, wenn überhaupt (Stichwort: Libraries), kommt denn noch alles auf den C++ Entwickler zu?
mit "usw." meinte ich, dass der Artikel von Shade noch deutlich länger ist. Ich habe ihn nicht ganz gelesen. Weiß nicht, was da noch kommt.
-
Lasst mich mal die Diskussion zusammen fassen.
Also was wir hier haben:
* Java hat Gegenüber C++ den Vorteil, das Index-Probleme nicht erlaubt sind
* C++ kann man so programmieren, das Index-Probleme nicht erlaubt sind
* Java hat Sicherheitsprobleme in seinen Werkzeugen
* Java hat irgend einen Sicherheits-Manager, der Java-Programmen spezielle Verbote auflegen kann (wenn er nicht gerade eine Sicherheitslücke hat) und das soll Java gegenüber C++-Programmen sicherer machen
* Jedes beliebige Programm (sowohl C++, als auch Java) kann man in einer VM betreiben um sich vor Schadhaften verhalten zu schützenGut. Das kann man ja auch wunderbar als Ende der Diskussion nehmen.
Mein Fazit: Es wurde nicht gezeigt, das Java mehr Sicherheit bietet.
-
Gregor schrieb:
finix schrieb:
Um. Ja.
Soll ich jetzt die JNI-Dokumentation zitieren um zu zeigen was auf den Java-Entwickler so alles zukommt? ( )Oh man. Du willst mir bei einem "Java ist plattformunabhängig" vorhalten, dass man auch mit Java fremden Code nutzen kann, der in anderen Programmiersprachen geschrieben ist? Das ist echt kreativ!
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.
Gregor schrieb:
finix schrieb:
Was meinst du eigentlich mit diesem ominösen "usw"? Was, außer dem wrappen von plattformspezifischem Code, wenn überhaupt (Stichwort: Libraries), kommt denn noch alles auf den C++ Entwickler zu?
mit "usw." meinte ich, dass der Artikel von Shade noch deutlich länger ist. Ich habe ihn nicht ganz gelesen. Weiß nicht, was da noch kommt.
Ach so. Tschuldigung, ich dachte du wüsstest worüber du sprichst und hättest selber Argumente.
(Nicht dass wir uns missverstehen, Java ist toll, und bei z.B. Applets hat es durchaus einen gewaltigen Vorteil, aber viel weiter geht's auch nicht in Sachen Plattformunabhängigkeit.)
-
BTW: Ich möchte nochmal betonen, dass mögliche Sicherheitslücken in der JVM keinerlei Auswirkungen haben, wenn man dem Programm vertraut. Was ich damit meine, ist folgendes: Wenn man einen Browser in Java schreibt, ist es praktisch unmöglich, dass irgendwer durch eine manipulierte Homepage oder so Code einschleust, der dann ausgeführt wird. Die Sicherheitslücken der JVM betreffen nur Programme, die man direkt auf der JVM laufen lässt, denen man nicht vertraut. Solche Programme könnten rein theoretisch so eine Sicherheitslücke ausnutzen, um vielleicht aus der Sandbox auszubrechen. Für einen "Java-Browser" ist das aber irrelevant. Man kann in den Browser ansich keinen Code einschleusen, da dieser ja in Java geschrieben wäre und entsprechend keine Buffer overruns usw. vorkommen können. Entsprechend kann man von außen auch nicht zur JVM durchdringen und deren Sicherheitslücken ausnutzen. Naja, ok: Wenn man dem Browser vertraut, lässt man ihn ja eh nicht in einer Sandbox laufen, was aber auch nicht nötig ist. Wie schon gesagt: Soetwas wie diese JPG-Sicherheitslücke wäre in Java nicht möglich.
-
Mein Fazit: Es gibt Leute, die sind anderen Sprachen/ Technologien gegenüber aufgeschlossen. Und dann gibt es Leute, die sind es nicht.
In diesem Sinne...
-
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.
-
Ich weiss jetzt nicht, ob das C++ ist, aber das letzte prominente Opfer, dass mir jetzt spontan einfällt, ist das hier:
-
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.
Und wenn Du ansonsten von "C++ ist plattformunabhängig" sprichst, dann hast Du zwar recht, wenn man davon absieht, dass ziemlich viel Verhalten nicht direkt definiert ist bzw. nur schwache Zusicherungen existieren, aber der Funktionsumfang von C++ geht ja auch gegen 0. Du bist für fast alles auf irgendwelche Bibliotheken von Dritten angewiesen, die mehr oder weniger plattformunabhängig sein können. Qt gilt als plattformübergreifend, zeigt aber anscheinend trotzdem stark unterschiedliches Verhalten auf unterschiedlichen Plattformen. Ist das eigentlich bei vielen plattformübergreifenden C++ Bibliotheken so?
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.
-
Gregor schrieb:
BTW: Ich möchte nochmal betonen, dass mögliche Sicherheitslücken in der JVM keinerlei Auswirkungen haben, wenn man dem Programm vertraut. Was ich damit meine, ist folgendes: Wenn man einen Browser in Java schreibt, ist es praktisch unmöglich, dass irgendwer durch eine manipulierte Homepage oder so Code einschleust, der dann ausgeführt wird. Die Sicherheitslücken der JVM betreffen nur Programme, die man direkt auf der JVM laufen lässt, denen man nicht vertraut. Solche Programme könnten rein theoretisch so eine Sicherheitslücke ausnutzen, um vielleicht aus der Sandbox auszubrechen. Für einen "Java-Browser" ist das aber irrelevant. Man kann in den Browser ansich keinen Code einschleusen, da dieser ja in Java geschrieben wäre und entsprechend keine Buffer overruns usw. vorkommen können. Entsprechend kann man von außen auch nicht zur JVM durchdringen und deren Sicherheitslücken ausnutzen. Naja, ok: Wenn man dem Browser vertraut, lässt man ihn ja eh nicht in einer Sandbox laufen, was aber auch nicht nötig ist. Wie schon gesagt: Soetwas wie diese JPG-Sicherheitslücke wäre in Java nicht möglich.
pcwelt schrieb:
...
Eigentlich sollten Java-Applets in der so genannten "Sandbox", der Java-Laufzeitumgebung, ablaufen und nicht auf beliebige lokale Dateien zugreifen können. Ausnahmen sind signierte Applets, die als "trusted" (vertrauenswürdig) eingestuft sind. Durch die von Adam Gowdiak entdeckte Schwachstelle ist dies auch beliebigen "untrusted" Applets möglich. Sie können Dateien lesen und schreiben sowie installierte Anwendungen starten. Sie dürfen im Prinzip alles, was der angemeldete Benutzer darf. Eine ähnlich problematische Schwachstelle in Java Web Start wurde bereits im März bekannt und gestopft .
...http://www.pcwelt.de/news/sicherheit/113883/index.html
Ist die Meldung falsch?
-
Gregor schrieb:
finix schrieb:
Inwiefern sind denn die Probleme "viel geringer"?
Oh, lass uns doch mal gucken, was da auf den C++-Entwickler zukommt:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1014628.html
...
...usw.Bei Java sähe das so aus: "Du musst darauf achten, dass Du nicht künstlich irgendwelche Plattformabhängigkeiten in den Code einbaust."
Das Problem dreht sich also komplett um.
Ehm, du bist also der Meinung, das ich als C++ Programmierer mir meine eigenen Wrapper programmieren MUSS? Der Artikel zeigt nur, wie ich fehlende Platformübergreifende Libs selbst entwickeln KANN.
Aber ich kann wie jeder Java-Programmierer (dazu zähle ich übrigens auch!) auch fertige Platformübergreifende Libs verwenden. Das tue ich in C++ übrigens so ziemlich 100%ig, ich habe noch nie selber einen Wrapper bzgl. Plattformen geschrieben. Weil ich bisher immer fertige Platformübergreifende Libs gefunden habe. Du stellst es aber so hin, als ob jeder C++ Programmierer für seine Projekte erstmal Wochen lang Wrapper schreiben muß. Aber irgendjemand bei Sun hatte auch für die Java-Runtime erstmal Wrapper geschrieben, oder?
-
Ist das eigentlich bei vielen plattformübergreifenden C++ Bibliotheken so?
Keine Ahnung, aber ich hab regelmäßig Probleme, wenn ich meine C++ Programme, die mit gtkmm geschrieben sind, nach Windows portieren will. Mir fliegen dann immer Exceptions um die Ohren, die ich unter GNU/Linux nicht bekommen habe. Der Witz ist, dass ich keine Zeile plattformabhängigen Codes (außer vllt. der, der unter Windows die Shell mit FreeConsole() verschwinden lässt) verwendet habe.
Ergo gehe ich davon aus, dass die glibmm-DLL unter Windows hier das Problem darstellt. Schade.Wenn jede Lib so portabel wie boost wäre, dann wär's natürlich cool, aber das ist leider nicht ganz der Fall.
-
Zeus schrieb:
Ist die Meldung falsch?
Vermutlich nicht. Aber sie widerspricht auch nicht meiner Aussage. Ein Applet ist ein Programm, dem man im Allgemeinen nicht vertraut, das direkt auf der JVM läuft. Wenn so ein Programm durch eine Sicherheitslücke in der JVM aus der Sandbox ausbrechen kann, dann hat es entsprechend mehr Rechte.
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.