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

On 30.12.2014 15:28, Lothar Kimmeringer wrote:

Am 30.12.2014 um 13:51 schrieb Renee B:

...

Also dann am Besten aufhören C zu programmieren weil es wohl nicht bekannt ist dass Pufferüberläufe passieren können? Tatsaechlich bin ich dieser Meinung. Ausser dem geschmaelertem Ego des Programmierers gibt es eigentlich keinen Grund, auf eine Managed Sprache zu verzichten, sei es C#, Java, etc. die von vornherein solche Dinge vermeidet. Auf Treiberebene programmieren heutzutage wirklich die wenigsten.

Dann auch aber auch Schluss mit C# (kann im unsicheren Kontext ebenfalls Pufferüberläufe haben), Java (Pufferüberläufe mittels JNI), Python, ... Perl hat keine Pufferüberläufe, dafür andere Probleme. Und auch C#, Java, ... haben noch andere Probleme.

Dass so etwas - richtig angewendet - Schreibarbeit spart (was zum Vorworf des "write only codes" im Vortrag wurde), mag sein, Sourcecodeoptimierung hat aber nur selten langfristig zu positiven Effekten gefuehrt.

Ich rede nicht vom "golfen", sondern von gezielt weniger Schreibarbeit. Bleiben wir beim "List flattening": methoden_aufruf( @alle_argumente ) ist kürzer als methoden_aufruf( $alle_argumente[0], $alle_argumente[1], $alle_argumente[2], ...) und besser lesbar, besser wartbar, ... Vor allem wenn die Methode eine beliebige Anzahl von Parametern akzeptiert. Ich gebe Dir absolut Recht, dass man sich nicht *zu kurz* fassen sollte.

...

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. Mit GUIs habe ich zum Glueck nicht viel zu tun, daher bewege ich mich primaer im Bereich JUnit.

Du glücklicher. - Renée -- Perl / OTRS development: http://perl-services.de OTRS AddOn repository: http://opar.perl-services.de