Wie am besten anfangen?
-
~john schrieb:
gets() existierte schon vor der ANSI-Norm, wie konnte es also sein, daß dieser Dreck Einzug in die ANSI-Norm fand?
Ok, wo fängt man da an ...
(1) Mit gets() kann man sich sehr bequem Kommandos für einen Worker-Thread aus einer Message Queue, einer temporären Datei u.ä. pflücken, und das sogar ziemlich OS - unabhängig. Ich nehme an, Sie haben gets() bisher wohl nur als Lesefunktion für Konsoleneingaben kennengelernt, sonst würden Sie auch die Vorzüge von gets() kennen. Dazu nur soviel: Viele OS erlauben eine sog. Stream-Umleitung, gets() kann also auch mit Daten aus einer temporären Datei gefüttert werden.
(2) Man kann umgekehrt auch mit der sichersten Funktion der Welt unsicher programmieren, wenn man will.
(3) Arbeiten mehrere Leute an einem Projekt zusammen, dann haben sie idR nicht das Ziel, Funktionen eines Mitstreiters absichtlich mit fehlerhaften Parametern, zu kleinen Buffern oder sonstwie unter Missachtung der Sicherheitshinweise des Implementierers aufzurufen. Wenn es gar nicht vorgesehen oder gar unmöglich ist, dass eine derartige Funktion eines Tages von nicht-eingebundenen Dritten verwendet werden wird, sondern nur innerhalb des Teams, und zudem ihren Job hervorragend erfüllt, dann pfeift man eben auch auf die Sicherheitsbedenken (verständlicher Weise!) zu Gunsten eines optimierten Moduls. Niemand zwingt einen Programmierer dazu, seinen Quellcode zu öffnen und damit eventuelle Verwundbarkeiten oder Unsicherheitsfaktoren darin preiszugeben. Ist das Ding erst mal kompiliert, wird es ohnehin schwierig und aufwendig genug, derartige Sicherheitslücken (per Disassembly o.ä.) auszunutzen. Diejenigen, die sich diese Mühe antun, wird man auch trotz Super-Sicherster Programmierung nicht davon abbringen können, irgendwelche Verwundbarkeiten aufzuspüren und in boshafter Weise auszunutzen.
Aber alle anderen, 'ehrlichen' Anwender des Programms (99%) interessieren diese internen (aber eben nur innerhalb des Entwickler-Teams tolerierten) Sicherheitsbedenken ohnehin nicht, dafür können sie die Gewissheit haben, dass ihre Copy der Anwendung auch auf ihrem Uralt-Rechner noch das Maximum rausholt und sich nicht mit performance-technisch überflüssigen Doppel- und Dreifachprüfungen irgendwelcher Zeiger und Rückgabewerte beschäftigt, weil nämlich alle Entwickler des Teams an einem Strang gezogen haben und sie in eine Funktion niemals boshafter Weise eine 10 reinstecken, wenn nur 16 oder 32 erlaubt ist.
Alles klar?
--> Es krankt bei den modernen OOP-Entwicklern generell daran, dass sie den potentiellen Nutzern ihrer Monsterobjekte mit Misstrauen begegnen, was aber selbstverständlich unangebracht ist, wenn man man im Team arbeitet, jeden Beteiligten kennt, man sich aufeinander verlassen kann, da fällt es dann auch leichter diese Sicherheitsprobleme zu tolerieren, weil ja von der Source ohnehin niemals geplant ist, dass sie je open oder gar public wird.
Ein Hoch auf Closed Source
MFG
-
Ausnahmeerscheinung schrieb:
Ist das Ding erst mal kompiliert, wird es ohnehin schwierig und aufwendig genug, derartige Sicherheitslücken (per Disassembly o.ä.) auszunutzen. Diejenigen, die sich diese Mühe antun, wird man auch trotz Super-Sicherster Programmierung nicht davon abbringen können, irgendwelche Verwundbarkeiten aufzuspüren und in boshafter Weise auszunutzen.
WTF? Wir können Programme nicht zu 100% sicher machen, also können wir es auch gleich sein lassen?
-
Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.
-
ITPolizei schrieb:
Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.
Dann sollten wir es auch gar nicht mehr versuchen
-
ITPolizei schrieb:
Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.
Ich schreibe nur sichere Software. Warum sollte der Normalzustand durch die Presse gehen?
-
Schon klar, na dann fang mal bei den BigPlayern an wie Apple, MS, Oracle oder Adobe. Denn die haben es bis jetzt noch nicht geschafft sichere Software zu schreiben. Du wärst also der erste Mensch der sichere Software schreiben kann.
Ich glaube als Politiker würdest du auch sagen dass du immer die Wahrheit erzählst
An den Poster davor, klar sollte weiter versucht werden an die Software sicherer zu machen. Da die IT-Branche aber noch sehr jung ist kann man das eher mit Architekten vergleichen die aus ein paar Palmenblätter Behausungen bauen können, aber erzählen ein Wolkenkratzer wäre kein Problem.
In 50 Jahren werden die Menschen zurückblicken und darüber lachen das sich einige aus der heutigen Zeit als Softwarearchitekten bezeichnet haben.
Softwareentwicklung ist doch im Vergleich zu andere Branchen ein gigantisches Rumgepfusche.
-
Mir ist auch noch nicht bekannt dass es auch nur einen Menschen gibt der weiß wie man wirtschaftlich sichere Software schreibt. Wenn es den mal gibt bekommt der bestimmt den Nobelpreis
Wir fassen zusammen: Es gibt keinen der weiß wie man richtig Software entwickelt, aber die meisten lassen sich als Softwareentwickler einstellen. Ist schon geil, zum Glück gibt es das nicht in der Form in anderen Branchen.
-
Nobelpreiser schrieb:
Mir ist auch noch nicht bekannt dass es auch nur einen Menschen gibt der weiß wie man wirtschaftlich sichere Software schreibt. Wenn es den mal gibt bekommt der bestimmt den Nobelpreis
Das ist ja auch ein Widerspruch.
Wie mit den Autos. Wenn man X Monat braucht, um ein fehlerfreies Auto zu basteln, so kann man doch ein paar Tage früher abgeben und dafür kassiert man eine gewisse Fehlerwahrscheinlichkeit ein. Früher im Markt zu sein gibt mehr Kohle. Weniger Fehler zu haben, gibt mehr Kohle. Das Optimum ist nicht am Rand. Nicht bei 0 Zeit und 100% Fehler und nicht bei X Zeit und 0% Fehler. Irgendwo dazwischen. Warte nicht auf fehlerfreie Software aus dem Kaufhaus. Und auf keine fehlerfreien Autos.
-
Das ist Unsinn, da Software keine Hardware ist und daher mit keiner Mechanik verglichen werden kann. Diese kann alleine durch die Fertigung nicht immer 100% gleich sein.
-
Softwareentwicklung ist doch im Vergleich zu andere Branchen ein gigantisches Rumgepfusche.
Warum funktioniert denn die Welt dann ueberhaupt, so wie jetzt. Auf Basis von Software. Alles ein riesiger Pfusch.
-
nichtschluessig schrieb:
Das Thema Sicherheit ist in jeder Sprache wichtig und für jede Sprache gibt es auch genug Exploits wenn bestimmte Standardfunktionen einfach genutzt werden ohne deren Parameter zu validieren.
Wie willst Du den C-Lernenden beibringen, daß sie auf solche Dinge zu achten haben, wenn faktisch keinerlei Einstiegsliteratur auch nur erwähnt, daß diese Funktionen gefährlich sind? Es fehlt das notwendige Bewußtsein, daß diese Funktionen brandgefährlich sind. Daher sieht auch niemand die Notwendigkeit sich mit Informationen zu korrektem Programmentwurf zu versorgen. Das ist das Grundproblem! Insofern muß man in der Einstiegsliteratur damit anfangen, weil es sonst niemals gelernt wird.
Die Realität zeigt, daß die Selbsteinschätzung von C Programmierern, sie hätten das Problem im Griff, reine Utopie ist.
-
~john schrieb:
Die Realität zeigt, daß die Selbsteinschätzung von C Programmierern, sie hätten das Problem im Griff, reine Utopie ist.
Unsinn. Ich hab das Problem im Griff.