On 30.12.2014 12:20, Lothar Kimmeringer wrote:
Und die Frage bleibt bestehen: Welche anderen Bibliotheken/Applikationen sind in die gleiche Falle gefallen und wo warten die naechsten Probleme, die sich hieraus ergeben? Dass OTRS beim Thema CGI.pm und DBI.pm nicht dazu gehoert, freut mich. Ob's die einzigen Module sind, bleibt abzuwarten.
Mit Sicherheit sind/waren das nicht die einzigen Module. Bei OTRS wird das häufig aber nicht wirklich zu einem Problem werden - wenn denn andere Modul die in OTRS benutzt werden betroffen sind - da bei den meisten Modulen eine Zwischenschicht wie bei Kernel::System::Web::Request für CGI.pm und Kernel::System::DB für DBI dazwischenliegt und dann meist einen Kontext erzwingt. Wie das mit anderen Perl-Anwendungen aussieht weiß ich nicht. Heutige Frameworks für Perl-Webanwendungen (Dancer, Mojolicious, Catalyst) haben nachgebessert um die Programmierer vor sich selbst zu schützen und Flüchtigkeitsfehler zu vermeiden. Andere Bugs sind Modulen bestimmt zu finden - wie gesagt, Bugfreie Software existiert (sehr wahrscheinlich) nicht.
* - Probleme finden sich in jeder Sprache Ist kein wirkliches Argument. Man kann das auch anders ausdruecken: Jede Sprache deckt einen gewissen Anwendungsbereich ab und wenn man sie ausserhalb verwendet, faengt sich frueher oder spaeter Probleme ein.
Die meisten der heute weitläufig genutzten Sprachen geben sich nicht viel. Egal ob Python, PHP, Ruby, Perl, Java...
- 20 Jahre alte "Bugs" gibt's immer wieder mal, dieses Jahr wurden einige davon ja auch medial groß begleitet - Perl entwickelt sich auch weiter - "List flattening" ist Bestandteil jedes Perl-Einsteiger-Kurses. - Der Vortragende outet sich ja schon zu Anfang, dass er Perl-Hasser ist. Das Ranten vom Vortragenden[1] hat meiner Ansicht nach den validen Argumenten geschadet
Definitiv. Die Bugs in den Modulen zu zeigen ist richtig und den mit "quote()" kannte ich auch noch nicht. Wenn der Vortragendes sich darauf konzentriert hätte und Aber die Bugs in den Modulen disqualifiziert die Sprache noch nicht. Der Heartbleed-Bug in OpenSSL disqualifiziert auch nicht die Sprache "C", die Sicherheitslücken in WordPress-Plugins disqualifiziert die Sprache PHP nicht, die BufferOverflow-Lücke in socket.recvfrom_into disqualifiziert noch lange nicht Python. Dann müssten wir die komplette IT einstampfen.
und das Argument "das weiss doch jeder !elf" kam ja auch aus dem Publikum. In meinem Einsteigerbuch (ist aber auch schon 20 Jahre alt) findet sich das uebrigens nicht
Gut, ein so altes Perl-Buch kenne ich nicht. Ich programmiere seit 12 Jahren Perl und da war das "List flattening" (was der quote()-Bug ist) so ziemlich das was ich in der zweiten Woche gelernt habe. Aber auch wenn man noch so gut ist - egal in welcher Sprache - macht man Fehler. Wie kommt es sonst, dass auch im Linux-Kernel etc. Bugs sind. Wie viele BufferOverflows gibt es noch, obwohl doch jeder schon von zig Sicherheitslücken gehört hat, die darauf basieren. Das "List flattening" ist auch ein nettes Feature, das viel Schreibarbeit spart. Hier zu erwarten, dass das Array als Arrayreferenz übergeben wird ist definitiv die falsche Erwartung. Nur weil man aus Python oder anderen Sprachen kommt muss man das nicht als Bug sehen. Andersrum könnte ich auch sagen, Python ist verbuggt, weil es das Array als Arrayreferenz übergibt. Ich - als Perlprogrammierer - erwarte "List flattening". Es ist also eine Sache der Erwartungen. Der Bugzilla-Bug hat mit "List flattening" nichts zu tun sondern hat etwas mit "Kontexten" zu tun. Kontexte sind in der Tat etwas knifflig wenn man nicht aufpasst, sind aber auch sehr praktisch, Das "Lustige" ist, dass der Bugzilla-Bug (wahrscheinlich) nie als Bug aufgefallen wäre, wenn die Zeile mit dem "$cgi->param()" als erste in dem Methodenaufruf gestanden hätte. Es gibt ein paar Sachen, die bei Perl alles andere als optimal sind. Aber wer Perl programmiert lernt die Dinge häufig auch zu seinen Vorteilen zu nutzen. Und wenn man Unzulänglichkeiten kennt, kann man Ihnen grundsätzlich aus dem Weg gehen. Ich bin zum Beispiel schon vor ein paar Jahren dazu übergegangen, Funktionsaufrufe nicht in Parameterlisten von Methodenaufrufe oder bei Hashzuweisungen reinzunehmen. Denn das kann böse Überraschungen geben: my %hash = ( schluessel1 => funktion(), schluessel2 => 3, ); sub funktion { return; } hat *nicht* "undef" als Wert zu schluessel1. sondern es resultiert in my %hash = ( schluessel1 => (), schluessel2 => 3, ); was das gleiche ist wie my %hash = ( schluessel1 => schluessel2 => 3 ); was das gleiche ist wie my %hash = ( schluessel1 => 'schluessel2', 3 => undef );
und Fakt ist, dass es wohl doch nicht so durchgehend bekannt ist, wenn eine ganze Latte von Perlapplikationen (darunter eben Bugzilla) Fixes liefern muessen, weil sie darauf reinfielen.
Also dann am Besten aufhören C zu programmieren weil es wohl nicht bekannt ist dass Pufferüberläufe passieren können? Fehler passieren. Ich könnte wetten, dass die Person, die den Fehler in Bugzilla eingebaut hat von Listkontext etc. in Perl weiß und sich jetzt in den Hintern beißt dass der Fehler passiert ist. Von Fehlern kann sich keiner frei machen. Was man machen kann ist viel zu testen um die Programmierer zu unterstützen. Da ist OTRS bei den Backendmodulen ganz gut dabei, was Frontendsachen bzw. Requesthandling angeht besteht noch Nachholbedarf. Viele Grüße, Renée -- Perl / OTRS development: http://perl-services.de OTRS AddOn repository: http://opar.perl-services.de