mit der [...] Sicherheit [...] von C und C++ verbinden soll

[Kaliumhexacyanoferrat]

C? Sicherheit? Hab' ich was verpasst?

[autore]

Kaliumhexacyanoferrat schrieb:
--------------------------------------------------------------------------------
> C? Sicherheit? Hab' ich was verpasst?

Wahrscheinlich ist die "type safety" der statisch typisierten Sprachen im Gegensatz zu den dynamisch typisierten gemeint.

[darkfate]

Anscheinend hast du das wirklich.

Linux/Unix ist in C geschrieben und bilden den größten Teil der Enterpriseserver.
So ziemlich alle Bereiche wo Sicherheit sehr kritisch ist da wird auf C/C++ gesetzt.

Was dir wahrscheinlich einfällt sind unfähige Programmierneulinge.

[Ja Wa]

darkfate schrieb:

> So ziemlich alle Bereiche wo Sicherheit sehr kritisch ist da wird auf C/C++
> gesetzt.

Äh... und auf Java.

[darkfate]

Mir ist kein Enterprise Kernel bekannt der in Java geschrieben wurde.



1 mal bearbeitet, zuletzt am 11.11.09 10:51 durch darkfate.

[Ja Wa]

darkfate schrieb:
--------------------------------------------------------------------------------
> Mir ist kein Enterprise Kernel bekannt der in Java geschrieben wurde.

Du hast auch nicht "Kernel", sondern "Server" beschrieben und darunter habe ich "Application Server" verstanden. Dass Java irgendwo aufsetzen muss, ist klar. ;) Das ist dann meist C, richtig.

[Kaliumhexacyanoferrat]

darkfate schrieb:
--------------------------------------------------------------------------------
> Anscheinend hast du das wirklich.
>
> So ziemlich alle Bereiche wo Sicherheit sehr kritisch ist da wird auf C/C++ gesetzt.

Ich habe auf die schnelle keine verlässlichen Studien gefunden ... aber vielleicht machts ja auch die Menge der Zahlen:

- Verglichen mit C++ benötigt ein Java-Programm für die gleiche Funktionalität ~25% weniger LOC
- C++ hat etwa drei mal mehr Bugs / Hour
- C++-Code enthält i.d.R. ~35% mehr Defects als Java-Code
- Das Debuggen von C++ dauert verglichen mit Java etwa 3x länger

Java hier nur als Beispiel für eine typsichere Sprache mit VM. Bei solch einem Design fallen bereits im Voraus viele mögliche Fehlerquellen weg (Buffer Overflows etc.).

Sicherlich, C/C++ ist hinsichtlich systemnaher Programmierung (Kernel, Treiber, ...) das non-plus-ultra, aber auf höherer Ebene (z.B. Service-Oriented-Programming) findet sich genug Java-Code in Sicherheitsrelevanten Bereichen.

[MartinP]

*Augenzwinker*

[darkfate]

> - Verglichen mit C++ benötigt ein Java-Programm für die gleiche
> Funktionalität ~25% weniger LOC

Dafür kannst du mit C/C++ Sachen machen die mit Java womöglich nie realisiert werden können. Sowas wie direkte USB Ansteuerung ist PITA bei Java.

> - C++ hat etwa drei mal mehr Bugs / Hour
Kommt immer auf den Programmierer an. Nur weil manche sich nicht hinsetzen und den Code gut durchplanen und anschließend auf DoS,Overflows, falsche Ereignisse und nummerische Instabilitäten prüfen ist das kein Problem der Sprache sondern des voreiligen Programmierers.

> - C++-Code enthält i.d.R. ~35% mehr Defects als Java-Code
Häää?

> - Das Debuggen von C++ dauert verglichen mit Java etwa 3x länger
Kann ich ebenfalls nicht bestätigen.

> Java hier nur als Beispiel für eine typsichere Sprache mit VM. Bei solch
> einem Design fallen bereits im Voraus viele mögliche Fehlerquellen weg
> (Buffer Overflows etc.)
Eben nicht. Auch JAVA hat Buffer Overlows. Nur eben in der VM.

> aber auf höherer Ebene (z.B.
> Service-Oriented-Programming) findet sich genug Java-Code in
> Sicherheitsrelevanten Bereichen.

Java in sicherheitsrelevanten Bereichen? -> Amen!
Liegt aber wahrscheinlich an den FHs und UNIs. Da ist Java mittlerweile die erste Programmiersprache.

[darkfate]

Schwarzeneggers Checks wurden noch in Kobol berechnet :)

[Greindoch]

darkfate schrieb:

> Auch JAVA hat Buffer Overlows. Nur eben in der VM.

In welcher Sprache ist die VM programmiert?

[kirsche40]

> - Verglichen mit C++ benötigt ein Java-Programm für die gleiche
> Funktionalität ~25% weniger LOC
So pauschal ist das völliger Quatsch. Da müssen nämlich alle Zeilen Code mitgezählt werden, die im Framework von z.B. Java mitarbeiten. Und die sind definitiv mehr als die in einem gleichen C-Programm. Was Du meinst sind die LOC des Entwicklers, der selber Code schreiben muß. Das läuft dann also auf Zeitersparnis hinaus - nicht aber auf die Fehleranfälligkeit des Systems insgesamt. Mehr LOC bedeuten immer auch mehr mögliche Fehler. Da wird grundsätzlich das KISS-Prinzip verletzt. Siehe Suns Java-Bugtracker! Der quillt auch nach Jahren der Nutzung des Frameworks noch mit Fehlermeldungen über.

> - C++ hat etwa drei mal mehr Bugs / Hour
??? Seltsam. Der Linux-Kernel läuft z.B. extrem stabil. Hab ich was verpaßt? Dagegen kacken bei mir regelmäßig irgendwelche Java-Programme mit einer NPE ab. :)

> - C++-Code enthält i.d.R. ~35% mehr Defects als Java-Code
Huh. 99,9% aller Java-Coder erfinden Zahlen zu defects in anderen Sprachen - oder wie soll ich das jetzt mit Deinem Eingangsstatement "Ich habe auf die schnelle keine verlässlichen Studien gefunden" verstehen?

> - Das Debuggen von C++ dauert verglichen mit Java etwa 3x länger
??? Also wer da einen Unterschied merkt, der hat wohl einen systematischen Fehler im Layer 8.

> Java hier nur als Beispiel für eine typsichere Sprache mit VM. Bei solch
> einem Design fallen bereits im Voraus viele mögliche Fehlerquellen weg
> (Buffer Overflows etc.).
Dafür hat man trotz Abschaffung von Pointern und Einführung von Referenzen immer wieder die schönen NPEs. :)

> Sicherlich, C/C++ ist hinsichtlich systemnaher Programmierung (Kernel,
> Treiber, ...) das non-plus-ultra, aber auf höherer Ebene (z.B.
> Service-Oriented-Programming) findet sich genug Java-Code in
> Sicherheitsrelevanten Bereichen.
>
Sorry, das ist nun wirklich BWLer-Bullshit-Bingo. Bemühe einfach mal Secunia und den Sun-Java-Bugtracker, dann weißt Du, wie es mit der Sicherheit in Java aussieht! Bloß weil Millionen Fliegen Scheiße gut finden möchte ich noch lange kein Java in einer kritischen Umgebung an der Backe haben. AspectJ ist da übrigens mein Favorit in Sachen "aufgebohrter Sicherheit". Java, genauer J2EE, mag für simple Bussiness-Anwendungen Sinn machen. Aber sobald es was größeres wird stößt Java an seine Grenzen - wie jede andere Programmiersprache auch. Den Stein der Weisen hat eben immer noch niemand gefunden.

[Karamalx]

kirsche40 schrieb:

> Java, genauer J2EE, mag für simple Bussiness-Anwendungen Sinn
> machen. Aber sobald es was größeres wird stößt Java an seine Grenzen

Komisch. Dabei wurde J2EE doch genau dafür entwickelt.

[thorben]

darkfate schrieb:
--------------------------------------------------------------------------------
>
> Java in sicherheitsrelevanten Bereichen? -> Amen!
> Liegt aber wahrscheinlich an den FHs und UNIs. Da ist Java mittlerweile die
> erste Programmiersprache.


nein, es gibt noch ein paar professoren, die das ganze bullshit finden und einen erstmal C/C*+ beibringen, damit man dann programmieren kann und weiß was java eigentlich tut.
leider werden die blos immer weniger ;)

[Eris Discordia]

COBOL is ne Geldruckmaschine. Nach dem Studium ne Firma suchen die Legacysysteme in COBOL betreut. Dann heiszt es: B**ches und Fuffies im Club!

[DrAgOnTuX]

sofern man nicht in einer *nix umgebung arbeitet, dann doch lieber c#/f# als java.
der entwickler hat dabei mehr zeit sich um die lösung des problems zu kümmern. ein gutes framework welches einem viele möglichkeiten bietet, sowie eine sprache welche einem viel arbeit (weniger code -> weniger fehler) abnimmt.

so zumindest meine beruflichen erfahrungen in den letzten 5 jahren mit java,c#(,f#)

[darkfate]

Finde ich auch komisch dass sie trotz Bemühungen in dieser Hinsicht so kräftig versagen konnten. Vor allem bei Geschäftskundensoftware würde mich stören dass mein Quellcode jedem der einen Texteditor bedienen kann zugänglich ist. Java hat diesbezüglich ein ganz beschissenes Konzept mit ihren Class/Package mist.

[darkfate]

Wieso dann nicht gleich vernünftig Programmieren lernen?
Bei mir haben sich über die Jahre genügend Bibliotheken für jeden Mist angesammelt so dass ich getrost auf den Systemspezifischen Quatsch verzichten kann.

[DrAgOnTuX]

geht mir nicht anderst, keines meiner projekte kommt ohne eine "utility" klasse aus wo ich die nötigsten funktionen ablege welche ich übers ganze projekt verteilt brauche und vom framework selber nicht zur verfügung gestellt wird.
wenn ich aber mit dingen wie LINQ oder PLINQ und tasks anstatt threads arbeite, geht mir in zeitunkritischen projekten c/c++ am a**** vorbei, weil ich da einfach zu viel zeit vertrödel um endlich mal abstrakt zu sein und mich um das eigentliche problem (businesslogik/ui/mvc) kümmern zu können.

[AnApple]

http://www.heise.de/security/meldung/Luecke-im-Linux-Kernel-erlaubt-Root-Zugriff-Update-849799.html

Muss ich noch was zur Sicherheit sagen? ;-)