Geschwindigkeit vs. Sicherheit
-
nep schrieb:
Du kannst jedes Java-Programm mit einem SecurityManager als Parameter starten, den du so konfigurieren kannst, dass dieses Java-Programm z.B. nicht mal deine Umgebungsvariablen lesen darf. So viel zu diesem Thema...
Sorry, aber wieder so ein Beispiel, was ich über das OS abdecken kann. Ich muß bei Java die JAR per SecurityManager in ihrer Berechtigung einschränken? Ist ja i.O. Aber das kann ich auch mit Windows machen: "Ausführen als..." und dann führe ich die eine bestimmte Exe-Datei als Gast aus ohne mich ausloggen zu müssen.
Ich finde es immer beachtlich, das die Leute die Features der Java-VM/-Runtime aufführen, die ich auch schon in meinem OS eingebaut habe. Klar, Windows kann dann Fehler haben, aber auch die JavaVM! Also, was soll immer dieses "Ich mach das in Java einfach so." Ja, mein Gott, das mach ich halt über Windows, Linux oder BSD, weil das OS meine Runtime ist. Und VirtualPC habe ich auch kostenlos von MS, kann ich notfalls darin unbekannte Software sicher ausführen, wenn ich einen Level höher gehen will, bzgl. Sandbox.
Was ich sagen will: C++ ist nicht dazu verflichtet z.B. Sandbox-Features anzubieten. Das hat die Runtime auf der das C++-Programm läuft zu erledigen. Genauso wie Java als Sprache keine Sandbox kennt, sondern es die Java-Runtime/VM zu erledigen hat.
-
@Optimizer
Ada
Natürlich gibt es Sprachen, die Fehlerquellen ausschließen, die andere Programmiersprachen erlauben. Aber das geht eben nur für bestimmte Fehler.
Gut, Java verhindert Index-Fehler. Aber was ist mit "unsicheren Strings", da bietet Java AFAIK nichts, so etwas gibt es aber in Ruby. Dennoch gab es zB eine kritische Sicherheitslücke in Ruby on Rails. Ada ist stark Typprüfend und hat für viele bekannte Bugs Laufzeitprüfungen. Aber dennoch ist die Ariane5 explodiert, weil der Code nicht mit dem Flugverhalten klar kam.
Man kann eben nicht sichere Programme durch eine Programmiersprache erzeugen. Aber genau der Eindruck wird hier vermittelt.
Sichere Programme sind das Ergebnis von Erfahrung, akribischer Planung/Prüfung und vor allem durch klaren und gut wartbaren Code (und keine fette Code-Base). Das hat nichts mit Java oder wer weiß was zu tun.
(Nur der Vollständigkeit halber:
http://sunsolve.sun.com/search/advsearch.do?collection=SUNALERT&type=collections&sort=date&queryKey4="category:security" "availability, security" category:security&max=100
http://java.sun.com/sfaq/chronology.html
)
-
@rüdiger: Was sind "unsichere Strings"?
Niemand sagt hier, dass man durch die Nutzung einer bestimmten Sprache gleich absolute Sicherheit kriegt. Aber die Sprache ist sicherlich ein Faktor, der Sicherheit entweder begünstigt oder auch nicht.
-
rüdiger schrieb:
Solltest Du die Suche da nicht auf Java einschränken?
-
Gregor schrieb:
@rüdiger: Was sind "unsichere Strings"?
Ich würde vermuten, er meint Benutzereingaben, die natürlich immer mit größtem Mistrauen zu behandeln sind. Klar, dass man nen Benutzer-String nicht gleich in ein SQL-Statement einbaut.
Und natürlich macht Java sowas nicht von allein. Genauso wie keine Programmiersprache garantiert, dass die Rakete korrekt fliegt. Die Sicherheitsprobleme, die sich aus der Semantik des Programms ergeben, sind immer da. Kein Grund, sich noch mehr Probleme aufzuhalsen.
-
@net: Full ACK.
MfG SideWinder
-
Optimizer schrieb:
Gregor schrieb:
@rüdiger: Was sind "unsichere Strings"?
Ich würde vermuten, er meint Benutzereingaben, die natürlich immer mit größtem Mistrauen zu behandeln sind. Klar, dass man nen Benutzer-String nicht gleich in ein SQL-Statement einbaut.
Das sollte ja die PreparedStatemants von Java abdecken
-
Artchi schrieb:
Sorry, aber wieder so ein Beispiel, was ich über das OS abdecken kann. Ich muß bei Java die JAR per SecurityManager in ihrer Berechtigung einschränken? Ist ja i.O. Aber das kann ich auch mit Windows machen: "Ausführen als..." und dann führe ich die eine bestimmte Exe-Datei als Gast aus ohne mich ausloggen zu müssen.
Naja du hast gefragt wer dir garantiert, dass ein Java-Programm z.B. nicht einfach dein ganzes Home-Verzeichnis löscht. Wenn du eh schon ne andere Möglichkeit hast, dann brauchst ja auch nicht zu fragen...
Wobei ich aber einfach mal behaupten will, dass du mit dem SecurityManager viel feingranularer bestimmte Berechtigungen vergeben bzw. verweigern kannst, wie durch das Ausführen als Gast...Und in anderen Betriebssystemen geht das nicht so einfach, behaupte ich jetzt auch einfach mal so, ohne mich da groß auszukennenIch will ja auch nicht unbedingt behaupten, dass C++ deshalb schlechter oder unsicherer ist. Ich wollte nur sagen, dass Java schon von Haus aus einige Sichherheitsmechanismen bereitstellt, die du in C++ so ohne Weiteres nicht hast. Und deshalb könnte man schon sagen, dass Java, zumindest von Haus aus sicherer ist.
-
Hier mal ein sehr interessanter Ausschnitt aus dem Blog des Hydranode-Projektleiters (Hydranode ist ein Opensource-P2P-Client der umfangreichen Gebrauch von der STL und Boost macht):
My greatest regret with Hydranode is that I didn't create a messy codebase; if I did that, there'd be a full-sized team behind the project already; but as it stands now, there's very little hope someone will pick up this project's maintainance, since developers knowing sufficient amount of C++/STL/Boost are hard to come by in OSS community, as it turns out. Personally, I know about 2-3 developers who'd have sufficient skillset to continue this project at these quality levels, and all of them are busy with other things.
Lesson learned - well-written codebase will cause most coders to run away in fear, rather than join in. However, I would never call Hydranode a waste of time; it's a great CV/Resume entry for me (I've gotten multiple job offers over the world already, from people who've seen Hydranode codebase), I've mastered advanced C++ (I knew very little C++ when I started this project), and I learned quite a lot about user interface design, usability testing and so on - all very valuable. I wrote Hydranode because I wanted to learn; towards that end, Hydranode has been a major success. But Hydranode failed as OSS project; next time I start some OSS project (doubtful it'll happen though), I'll create a messy codebase using basic C++ (no template metaprogramming, design patterns or any other of that "advanced crap"), and I'm willing to bet large sums of money that developers come running to join in.
Quelle: http://hydranode.com/blog/index.html
Das spiegelt sehr schön wieder, was wir in der C++ Welt eigentlich haben: die wenigsten kennen C++ und ihre Designmöglichkeiten. Ich habe mal einem Java-Kollegen, der seit Jahren auch C und C++ kennt, mal ein paar Hinweise bzgl. Templates u.ä. gegeben. Er selber kannte kein Boost, keine Namespaces ("warum hat mir das keiner gesagt?") und vorallem hat er 3D-Engines wie Irrlicht benutz. Mit dem Hinweis auf Templates und das diese nützlich sind und vorallem eine andere Denkweise als Java bedürfen, meinte er "Ja, aber die ganzen Frameworks wie Irrlicht werden von erfahrenen C++lern entwickelt, und ich habe noch nie Templates oder sowas darin gesehen! Die werden es ja wohl wissen?"
Eigentlich ist dieses Topic hier mal wieder so richtig sinnlos, weil bestimmt 99% der C++-Programmierer auf diesem Planeten kein Buch über die STL in der Hand hatten. Wenn man also mal wieder bei heise.de liest, das irgendwo ein Bufferoverrun ist, dann kann man davon ausgehen, das der Täter anscheinend keine Ahnung von C++ hat. Und das Hydranode-Projekt ist ein Belegt dafür.
-
Aspekte wie Sicherheit, Ergonomie, Design sind stark abhängig von Programmiere nicht von der Sprache/Framework. Sicher durch die Manageebene von Java und .Net wird der Programmiere entlasten von einige Sorgen, aber wenn ich eine Schadensfunktion in Java oder C++ realisiere, dann macht das die Applikation, ausser ich gebe der Applikation einen Sicherheitscontext, wo sie kein Schaden anrichten kann (Aber das geschieht eher selten oder? Hat Jemand sein Internetbrowser als Gast laufen?).
-
Erfrischend wär mal eine "Deutsch-vs-Französisch-Diskussion" (ich will ja nicht Flamewar sagen), aber ansonsten lerne, bzw. favorisiere ich einfach jene Sprache, die mir Arbeit und in Folge daraus Geld verschafft. Java ist für mich mehr als nur eine Sprache, bzw. für die Klugscheisser unter uns eine Runtime, sondern viel mehr auch sämtliche Tools, Frameworks und Communities, die dahinter stehen. Etwas ideologisch betrachtet ist es für mich momentan einfach der Ursprung der Innovation.
groovemaster schrieb:
Gute Frage. Schon mal aufgefallen, dass solche Sachen meistens von Java Anhängern ins Leben gerufen wird? Man mag ja 'ne Menge guter Sachen an Java finden, eine tolerante Community scheint wohl eher nicht dazu zu gehören.
Ein Troll hat diese Diskussion ins Leben gerufen, kein Java Anhänger. Außerdem habe ich eher den Eindruck, dass Java eher von allen Seiten angegriffen wird (Java - C++, Java - C#, neuerdings auch Java - Groovy, bzw. Java - Ruby, ...).
-
java anhänger schrieb:
Außerdem habe ich eher den Eindruck, dass Java eher von allen Seiten angegriffen wird (Java - C++, Java - C#, neuerdings auch Java - Groovy, bzw. Java - Ruby, ...).
Java vs. Groovy? Soetwas habe ich noch nicht gesehen. Wo gibt es denn solche Diskussionen?
-
java anhänger schrieb:
Java ist für mich mehr als nur eine Sprache, bzw. für die Klugscheisser unter uns eine Runtime, sondern viel mehr auch sämtliche Tools, Frameworks und Communities, die dahinter stehen.
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
-
TactX schrieb:
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
Mir kommt es immer so vor, als ob die C++ler bei allen möglichen Vorteilen von Java sagen: "Aber da habe ich ein Beispiel, bei dem das nicht so gut klappt. Also ist der ganze Vorteil zu negieren, nicht vorhanden."
Das stimmt natürlich nicht. Die Vorteile, die Java bietet, sind nicht als "absolute Vorteile" zu verstehen, sondern nur relativ im Vergleich zu anderen Sprachen, wie zum Beispiel C++. Ein Negativ-Beispiel macht den Vorteil nicht zu nichte. Was viel mehr zählt, ist die Wirksamkeit des Vorteils im Gesamten. Wenn so ein Vorteil viele Probleme behebt, dann ist es immer noch ein Vorteil, auch wenn er nicht alle Probleme behebt.
Das kann man auf Sicherheit beziehen, das kann man auf Plattformneutralität beziehen und auch noch auf andere Eigenschaften, die Java von deren Befürwortern gerne zugeschrieben werden. 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 entsprechende JRE für die entsprechenden Plattformen existiert.
-
Gregor schrieb:
TactX schrieb:
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
Mir kommt es immer so vor, als ob die C++ler bei allen möglichen Vorteilen von Java sagen: "Aber da habe ich ein Beispiel, bei dem das nicht so gut klappt. Also ist der ganze Vorteil zu negieren, nicht vorhanden."
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...
PPS: Ich bin kein C++ler. Tut hier aber nichts zur Sache.
-
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.