Geschwindigkeit vs. Sicherheit

rüdiger

SideWinder schrieb:

@rüdiger: Du investierst in die falsche Sprache. Deine absolut unwirtschaftlichen Ausbrüche solltest du dir für C aufheben, dort ist Linux zu Hause

Bitte?!

Gregor

otze schrieb:

rüdiger schrieb:

Taschenlampe schrieb:

Wieso sagt eigentlich kein C++ befürworter was zu dem 2038er Problem?

Welches 2038er Problem?

Das jahr 2000 problem, halt nur mit 32 bit

ist aber imho echt kein problem, da im jahre 2038 wohl kein jetziges programm mehr im umlauf sein wird(technologie entwickelt sich halt weiter, ne?), und bis dahin time_t wohl schon lange 64bit hat.

Das ist IMHO genau die Mentalität, die dann letztendlich zu einem y2038-Problem führen wird. War ja beim y2k-Problem genauso. ...wobei das y2k-Problem vielleicht überbewertet wurde. Letztendlich ist man zu diesem Problem gekommen, weil sich die Leute irgendwann gesagt hatten: Zu der Zeit wird mein Programm ja eh nicht mehr eingesetzt. Und das war halt falsch.

So ein Problem würde vermutlich auch bei Java auftreten... ich gehe allerdings tatsächlich davon aus, dass Java im Vergleich zu C++ eine kürzere Halbwertszeit hat. 2038 wird man von Java auf eine andere Technologie umgestiegen sein. Damit meine ich nicht C++, sondern eine Technologie, die heute noch nicht da ist. C++ wird da IMHO länger leben. Grund: C++ ist flexibler, was die Anpassung an neue Technologien betrifft. Java wird da hingegen in absehbarer Zukunft ein paar Probleme bekommen. ...zum Beispiel, was die 64Bit-Fähigkeiten heutiger Prozessoren betrifft. Mit Java kann man die nicht so gut ausnutzen: Versuch mal, in Java ein Array mit 5 Mrd. Einträgen zu erstellen. Da wirst Du scheitern, auch wenn Du eine 64-Bit JVM hast.

Gregor

Artchi schrieb:

Wenn dir Smartpointer auch nicht reichen, nimm Hans Boehms Garbagecollector. Dann biste mit C++ auf Java-Level.

Huh? Die Standardantwort auf alle Java-Vorteile gegenüber C++? "Aber man kann ja Java mit C++ nachbauen." ...zumindest mehr oder weniger.

SideWinder schrieb:

@Optimizer: Das beispiel liefert wenn mich nicht alles täuscht einen Compilerfehler in meinem VC...

int* test() {
	for( int i = 0;  i < 10;  ++i )
		if( i == 10 )
			return 0;
}

int main() {
	int* blubb = test();
	int i = *blubb;
}

Compiliert. In diesem billig-Fall kriegt man natürlich noch ne Warnung.

Artchi schrieb:

Wenn dir Smartpointer auch nicht reichen, nimm Hans Boehms Garbagecollector. Dann biste mit C++ auf Java-Level.

Überhaupt nicht. Ein konservativer Garbage Collector (und keinen anderen kann man für Standard C++ implementieren) erreicht nicht annähernd eine vergleichbare Performance, da schlichtweg alle Algorithmen verboten sind, die Objekte verschieben würden. Das sind aber genau die Algorithmen, die heute in allen praktisch relevanten GCs implementiert sind.

Desweiteren kann er verlassene Objekte nicht immer zuverlässig identifizieren (was die Definition eines konservativen Collectors ist). Das ist unerwünscht, wenn man den GC benutzt, um vergessene Handles und Socket-Verbindungen aufräumen zu lassen. C++ mit einem gescheiten GC wäre zum Beispiel C++/CLI - hierfür waren Spracherweiterungen nötig.

groovemaster

lolz schrieb:

Warum lasst ihr euch eigentlich immer wieder auf eine Java vs. C++ Diskussion ein?

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.

Gregor schrieb:

Hmmm... Die C++ler sehen immer sämtliche Schuld beim Programmierer, die Javaleute gehen hingegen davon aus, dass es den perfekten Programmierer, der keine Fehler macht, nicht gibt.

Ich denke, jeder der einschlägige Erfahrung mit Programmieren hat, wird das so sehen. Vollkommen unabhängig von der Sprache. Ich habe allerdings das Gefühl, dass durch die mittlerweile einfache Zugänglichkeit von Entwicklungstools zu viele glauben, sie könnten mal schnell Programmierer werden. Und regen sich dann auf, wenn eine Sprache für Ahnungslose zu viel Unsinn zulässt. Es gehört halt mehr dazu, als irgendwelchen Code in einen Editor abzutippen und sich jede Zeile in einem Forum vorkauen zu lassen.

Gregor schrieb:

Das ist ja auch ein Grund, warum die Javaleute eben Java nutzen: Da werden viele Fehler, die einem mit C++ assieren können, nicht ermöglicht.

Was ja auch absolut ok ist. Aber für andere gibt es diese Notwendigkeit vllt. nicht. Soll das eine deshalb besser sein als das andere?

Optimizer schrieb:

Das können Fehler im Speicher-Management sein zum Beispiel ein Objekt zweimal gelöscht.

Und was hat das mit C++ zu tun, wenn ein Container kaputt ist? Dann wird er halt gefixt. Am Clientcode ändert das jedoch rein gar nichts.

Optimizer schrieb:

Oder Funktionen, die nichts zurückgeben (== einen uninitialisierten Speicherblock zurückgeben), was C++ ja genialerweise erlaubt.

Häää? Entweder du gibst etwas zurück oder nicht, dazwischen gibt es nichts.

Optimizer schrieb:

Oder generell uninitialisierte lokale Variablen, was C++ ja genialerweise erlaubt (schön, dass man die Möglichkeit hat).

Auch in C++ ist RAII immer noch eine feine Sache. Und was soll das denn überhaupt für eine Argumentation sein? Soll ich jetzt kein Auto mehr kaufen, weil ich damit an einen Baum fahren kann?

Optimizer schrieb:

Natürlich ist es möglich, auch in C++ ein fehlerfreies Programm zu entwickeln. Auch in einer beliebigen Assembler-Sprache und in Brainfuck ist es möglich. C++ und die anderen Alternativen (;)) haben aber ein paar Eigenarten, die das nicht gerade unterstützen und da Menschen programmieren, passieren Fehler.

Nö. Du kapierst überhaupt nicht worum es geht. Es geht nicht darum, dass ein perfekter Programmierer ohne Fehler fehlerfreie Anwendungen entwickeln kann. Es geht darum, dass du in C++ die Möglichkeit hast, entsprechende Alternativen zu nutzen, um, ohne sich den Kopf zerbrechen zu müssen, ebenfalls sicher entwickeln zu können.

byto schrieb:

Dieser Segen sorgte halt bis dato für zahllose Sicherheitslücken und gott-weiss wieviel Milliarden Dollar Schaden. Aber offenbar war das alles bloß von Newbs zusammengefrickelter Code, während die Sicherheitsexperten alle hier im Forum sitzen.

Netter Versuch, aber leider zu plump. Ich gehe mal davon aus, du sprichst hier Windows an. Da die relevanten Teile aber in C entwickelt wurden, ist das Offtopic.
Und bevor hier jetzt noch jemand mit irgendwelchen sinnlosen Wunschvorstellungen über den Berg kommt, bitte nur mit aussagekräftigen Statistiken oder Belegen. Ansonsten hat das keinen Sinn.

SideWinder schrieb:

Das Y2K-Problem ist anderer Natur. Unabhängig davon hat Java dieses Problem allerdings nicht: Eine neue JRE löst das Problem.

Und wo ist das Problem bei C++? Ein neuer Standard wird das Problem auch lösen. :p

volkard

Optimizer schrieb:

Natürlich muss man da differenzieren. Es gibt Sicherheitsprobleme, die man mit keiner Sprache der Welt verhindern kann. Aber ein erstaunlich hoher Anteil sind buffer overruns, eine Trivialität eigentlich. Da hilft aber kein std::vector dagegen, denn die Ursachen sind meistens viel tiefgründiger als direkt ein falsch gesezter Index.

ja. linuxer, die weiterhin c coden. und selbst, wenn sie nen c++-compiler benutzt haben, bleibt es c-stil.

volkard

Optimizer schrieb:

Oder generell uninitialisierte lokale Variablen, was C++ ja genialerweise erlaubt (schön, dass man die Möglichkeit hat).

bau nen konstruktor und der default-konstruktor ist weg. schon geht es nicht mehr, so ein objekt uninitialisiert zu lassen. wo ist dein problem?
und uninitialisierte variablen sind wirklich ein anfängerfehler. damit überzeugst du keinen.

volkard

Optimizer schrieb:

Damit meine ich zum Beispiel:
MyClass* foo() {
    for( ... )
         if( ... ) // programmierer denkt, das wird irgendwann schon true
              return irgendwas;
}
Nicht dass ich das für ein ernsthaftes Problem halten würde.

isses auch nicht. der compiler warnt.

Optimizer schrieb:

Aber ich würde auch einen möglichen buffer overflow allein nicht für ein ernsthaftes Problem halten. Aber an lauter solchen Trivialitäten erkennt man, dass man es im C++ Standard wohl nicht so wichtig mit der Sicherheit nimmt.

ich muß schon mit gewalt die warnung ignorieren, und zusätzlich doof sein, um da was unsicheres zu bauen. also ist dein argument mal völlig irrig. und das aufrufen von hundert nullargumenten macht dich auch nicht glaubwürdiger.

rüdiger

Gregor schrieb:

otze schrieb:

rüdiger schrieb:

Taschenlampe schrieb:

Wieso sagt eigentlich kein C++ befürworter was zu dem 2038er Problem?

Welches 2038er Problem?

Das jahr 2000 problem, halt nur mit 32 bit

ist aber imho echt kein problem, da im jahre 2038 wohl kein jetziges programm mehr im umlauf sein wird(technologie entwickelt sich halt weiter, ne?), und bis dahin time_t wohl schon lange 64bit hat.

Das ist IMHO genau die Mentalität, die dann letztendlich zu einem y2038-Problem führen wird. War ja beim y2k-Problem genauso. ...wobei das y2k-Problem vielleicht überbewertet wurde. Letztendlich ist man zu diesem Problem gekommen, weil sich die Leute irgendwann gesagt hatten: Zu der Zeit wird mein Programm ja eh nicht mehr eingesetzt. Und das war halt falsch.

32 Jahre sind schon sehr lang. Natürlich wird bis dahin vermutlich noch viel Software eingesetzt, die zumindest einen Ursprung in heutiger Software hat (Auch wenn sich alle paar Monate/Jahre eine neue Technologie aufzwingt, bei einigen Dingen ist die Software-Branche wirklich langläufig). Aber zumindest wird in vielen Bereichen die Hardware ausgetauscht sein, da diese ja in der Regel auf kürzere Zeiten ausgelegt ist. Das Problem betrifft ja im Grunde 32Bit-Systeme, die dürften wohl 2038 eher einen kleinen Teil ausmachen.

Gregor schrieb:

So ein Problem würde vermutlich auch bei Java auftreten... ich gehe allerdings tatsächlich davon aus, dass Java im Vergleich zu C++ eine kürzere Halbwertszeit hat. 2038 wird man von Java auf eine andere Technologie umgestiegen sein. Damit meine ich nicht C++, sondern eine Technologie, die heute noch nicht da ist. C++ wird da IMHO länger leben. Grund: C++ ist flexibler, was die Anpassung an neue Technologien betrifft. Java wird da hingegen in absehbarer Zukunft ein paar Probleme bekommen. ...zum Beispiel, was die 64Bit-Fähigkeiten heutiger Prozessoren betrifft. Mit Java kann man die nicht so gut ausnutzen: Versuch mal, in Java ein Array mit 5 Mrd. Einträgen zu erstellen. Da wirst Du scheitern, auch wenn Du eine 64-Bit JVM hast.

Optimizer schrieb:

SideWinder schrieb:

@Optimizer: Das beispiel liefert wenn mich nicht alles täuscht einen Compilerfehler in meinem VC...
int* test() {
	for( int i = 0;  i < 10;  ++i )
		if( i == 10 )
			return 0;
}

int main() {
	int* blubb = test();
	int i = *blubb;
}
Compiliert. In diesem billig-Fall kriegt man natürlich noch ne Warnung.

Wie würde das Beispiel durch den Einsatz von Java sicherer werden?

Ich verstehe einfach nicht, wie man so eine Panik um Bufferoverflows verbreiten kann und dann als Lösung eine Programmiersprache vorschlägt, dessen VM genau solche Probleme en mas hat(te.

Aber im Grunde sollten wir mal erkennen, dass das Problem nicht ist, das wir die gesamte Software auf Java portieren sollten, sondern da die meiste Software so eine alte große und unübersichtliche Code-Base hat.

volkard schrieb:

Optimizer schrieb:

Aber ich würde auch einen möglichen buffer overflow allein nicht für ein ernsthaftes Problem halten. Aber an lauter solchen Trivialitäten erkennt man, dass man es im C++ Standard wohl nicht so wichtig mit der Sicherheit nimmt.

ich muß schon mit gewalt die warnung ignorieren, und zusätzlich doof sein, um da was unsicheres zu bauen. also ist dein argument mal völlig irrig. und das aufrufen von hundert nullargumenten macht dich auch nicht glaubwürdiger.

Schau, deswegen mag ich keine Beispiele bringen. Es nützt nichts, dazu zu sagen, dass der Compiler in diesem Fall warnt, weil i nur bis 9 läuft und er das erkennen kann. Man wird trotzdem wieder genau auf die Warnung festgenagelt. Das ist doch Mist. Du glaubst doch selber nicht, dass es keinen Fall geben kann, wo der Compiler nicht warnt.

rüdiger schrieb:

Wie würde das Beispiel durch den Einsatz von Java sicherer werden?

Java compiliert das nicht.

Ich verstehe einfach nicht, wie man so eine Panik um Bufferoverflows verbreiten kann und dann als Lösung eine Programmiersprache vorschlägt, dessen VM genau solche Probleme en mas hat(te.

Ich schlage keine Sprache vor. Ich stelle vor, dass Java (nicht als einzige Sprache) ein ausgereiftes Konzept hat, um buffer overflows zu verhindern. Was die VM damit zu tun hat, ist mir ein Rätsel. Schließlich ist das ein Implementierungsdetail, genauso wie ein C++ Compiler falschen Code generieren könnte. Wir reden doch über Sprachen und darin eingebaute Sicherheit, oder?

Java ist mir selber doch egal. Ich habe weder beruflich noch privat was mit Java zu tun und kann darauf verzichten.

volkard

Optimizer schrieb:

Es nützt nichts, dazu zu sagen, dass der Compiler in diesem Fall warnt, weil i nur bis 9 läuft und er das erkennen kann. Man wird trotzdem wieder genau auf die Warnung festgenagelt. Das ist doch Mist. Du glaubst doch selber nicht, dass es keinen Fall geben kann, wo der Compiler nicht warnt.

hä?
er warnt, weil nicht jeder kontrollpfad auf ein return läuft. das KANN er erkennen. in jedem fall. außerdem mach ich warnungen zu fehlern. was ist dann daran schlimm, auf die warnung festgenagelt zu sein? das ist doch, wie, wenn es die sprache nicht zuließe. ich kann aber, wenn es ich für ganz dringend nötig halte, überschreiben. ich durchsuche gerade mal meine platte, ob ich sowas auch noch habe.
edit: ja, habs aber nur in einer datei gefunden. ein switch auf einen enum mit lauter return aber ohne default.

Ok. Hätte man eigentlich zur Pflicht machen können.

rüdiger

Optimizer schrieb:

rüdiger schrieb:

Wie würde das Beispiel durch den Einsatz von Java sicherer werden?

Java compiliert das nicht.

Ich weiß jetzt so spontan gar nicht, ob ein C++-Compiler das kompilieren muss. Aber selbt wenn, es reicht doch, das er warnt. Natürlich wäre es toller, wenn er so etwas nicht kompiliert und wir eine magische Programmiersprache hätten, die alle Fehler verhindert. Aber hey, ob der Compiler nun das Detail schluckt oder die XSS-Schwachstelle in deinem Java-Programm. (Komm mir nicht mit, das letztere könnte man nicht erkennen. Ruby kann das).

Ich verstehe einfach nicht, wie man so eine Panik um Bufferoverflows verbreiten kann und dann als Lösung eine Programmiersprache

vorschlägt, dessen VM genau solche Probleme en mas hat(te.

Ich schlage keine Sprache vor. Ich stelle vor, dass Java (nicht als einzige Sprache) ein ausgereiftes Konzept hat, um buffer overflows zu verhindern. Was die VM damit zu tun hat, ist mir ein Rätsel. Schließlich ist das ein Implementierungsdetail, genauso wie ein C++ Compiler falschen Code generieren könnte. Wir reden doch über Sprachen und darin eingebaute Sicherheit, oder?

Gut, Java bedingt eben eine große VM und daher viel Code, der geschrieben wird. Viel Code ist Fehleranfällig (praktisch bewiesen durch die Fehler, die in der VM waren). Ergo, ist es keine gute Idee Sicherheit durch mehr Code zu erreichen. Das ist mein Punkt.

Aber bitte, wenn wir alle der Meinung sind, das Java hier als Beispiel fehl am Platz ist oder zumindest irrelevant, dann können wir uns ja auf eine Alternative einigen, die wir hier diskutieren.

nep

Artchi schrieb:

Hem, und wer garantiert mir, das nicht ein beliebiges Java-Programm, welches ich mir aus dem Netz lade (egal ob über WebStart oder so zum entpacken) nicht auch mein Homeverzeichnis löscht? Das kann die JVM nämlich auch nicht verhindern, denn jedes Java-Programm (außer Applets) kann Dateioperationen ohne Nachfrage ausführen. In dem Fall auch mal locker rekursiv mein Home löschen.

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...
Ich finde es immer wieder lustig wie sich die Leute hier von beiden Seiten gegenseitig zerfleischen, und was da z.T. für schwachsinnige Kommentare abgegeben werden. Fehler macht jeder Programmierer, auch wenn er noch so perfekt ist, und da spielt auch die Sprache keine Rolle.
Java verfolgt einfach eine andere Philosophie als C++, deshalb ist es IMHO auch schwachsinnig ständig jeden einzelnen Bereich der beiden Sprachen zu vergleichen um dann zu sagen, dass die andere ja doch viel besser ist. Es gibt Bereiche für die Java "besser" geeignet ist, und es gibt auch Bereiche für die C++ "besser" geeignet ist und es gibt eben auch Bereiche in denen beide Sprachen etwa gleichwertig sind. Wo ist das Problem ? Ich programmiere z.B. in beiden Sprachen und wenn ich ein neues Projekt anfange, dann entscheide ich mich eben für diejenige Sprache von der ich denke, dass sie besser geeignet ist...

Achja, aber mal zum Thema... in Java gibt es viele Sicherheitsmechanismen schon von Haus aus, wie eben z.B. den SecurityManager um nur mal einen zu nennen... Nur kennen das viele Leute gar nicht, deshalb kann man schon sagen, dass Java - zumindest von Haus aus - sicherer als C++ ist. Übrigens... in Java gibt es auch viele Fallstricke... die sind zwar "anders" als die von C++, aber die gibt es dennoch, und deshalb sind so Aussagen wie "Jeder schlechte Programmierer kann in Java gute Programme schreiben; in C++ geht das aber nicht" einfach nur daneben.

@rüdiger:

Bzgl. Alternativen: Ich probiere nicht alles freakige sofort aus, aber ich habe Erfahrungen (unterschiedlichen Ausmaßes) beispielsweise in C++, C, Java, C#, Prolog, Lisp, PHP, Python, verschiedene Basic-Dialekte und desweiteren gemacht. Vor allem Sachen wie Prolog sind, denke ich, auch mit einer gewissen Umstellung in der bekannten Denkweise verbunden. Ich mag auch nicht alle Sprachen davon außer C++.

Aber bei allen Sprachen habe ich eigentlich immer nur entdeckt, dass es völlig unmöglich ist, buffer overflows zu erzeugen - außer in C und C++. Das ist sozusagen ein Alleinstellungsmerkmal Also welche Alternativen möchtest du diskutieren? Gibt es denn jetzt irgendeinen Grund zu glauben, dass ausgerechnet C++ für sicherheitskritische Anwendung toll ist?

Sind denn alle anderen Sprachen für n00bs? Bei solchen Themen kommt es echt immer so rüber, dass alle Menschen, die je Sicherheitslücken verursacht haben, Idioten sind. Ich glaube das nicht, ich glaube vielmehr dass man aus gutem Grund einen Schutz vor solchen und anderen trivialen Fehlern in die Sprachen einbaut.

Und deshalb hilft auch das Argument "sowas triviales, wer das falsch macht, ist wirklich selber schuld" nicht - es geht genau um Trivialitäten.

Artchi

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.

rüdiger

@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
)

Gregor

@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.

Gregor

rüdiger schrieb:

http://sunsolve.sun.com/search/advsearch.do?collection=SUNALERT&type=collections&sort=date&queryKey4="category:security" "availability, security" category:security&max=100

Solltest Du die Suche da nicht auf Java einschränken?