Moin Moin!

»» »» Warum gibt es keine Analyse in der Form, die du gerade präsentiert hast?
»» »» So bleibt die Neutralität gewährleistet und man kan anhand objektiver Kriterien entscheiden.

Hm, "neutral"...

Ich hab nie behauptet, dass meine Postings neutral seien.

»» Jetzt gibt es sie. Die beiden verlinkten Seiten gibt's aber schon etwas länger, und dort gibt es auch nochmal ganz ansehnliche Linksammlungen.

Ja, aber sie sind auch schon uralt und beziehen sich auf die Situation vor fünf Jahren.
Seitdem hat sich bei PHP eine Menge getan. Und bei Perl?

Vor 5 Jahren: 5.8.3
Heute: 5.10.0 (Release-Datum: 18. Dezember 2007)
Nahe Zukunft: 5.10.[1-5]
Ferne Zukunft: 5.12.x, 6.0

Dokumentation der Änderungen: ->5.8.4 ->5.8.5 ->5.8.6 ->5.8.7 ->5.8.8 ->5.10.0

»» Ich gebe zu, dass ich zwei Standard-Aussagen von mir zu PHP schlicht und ergreifend vergessen habe, die ich meinen Kunden und Chefs immer wieder an den Kopf werfe:
»»
»» 1. "Pubertierende Hauptschüler Programmieren"
»» 2. "Es gibt zwei Arten, PHP zu betreiben: Unsicher und abgeschaltet."

Zwei Polemiken, die nicht gerechtfertigt sind.

»» Nummer 1 ist ein Doppel-Vorurteil, das ich in aller Regel etwas länger begründe. Kurz gesagt ist die Code-Qualität bei PHP oft unter aller Sau, weil PHP es so leicht macht, auf den ersten Blick brauchbare Ergebnisse zu produzieren.

Bei Perl genauso. Die Qualität des Codes hängt direkt proportional von den Fähigkeiten des Programmierers ab, aber gar nicht von den Eigenschaften der Programmiersprache.

»» Bei genauerer Betrachtung stellt man dann aber fest, das sehr viel fehlt: Sicherheitsprüfungen, edge cases, locking, escaping, usw. PHP ist ein hervorragendes Rapid Prototyping Tool für Web-Anwendungen, eben weil man schnell eine Demo zusammenhacken kann. Aber für den Produktiveinsatz ist eine solche Demo in aller Regel ungeeignet, und PHP steht dem Entwickler dann sehr im Weg, wenn er aus der Demo eine Produktivversion bauen soll.

Du wirst zugeben, dass diese Behauptung schlicht unbewiesene Polemik ist. Nimm einen Programmierer, der Perl schlecht kann, und lass ihn irgendeine Demo zusammenhacken, da wird auch Code rauskommen, den man eigentlich direkt in die Tonne tritt, wenn's danach weitergehen und produktiv werden soll.

»» Nummer 2 ist eine grobe Vereinfachung. Natürlich kann man PHP sicher betreiben, aber der notwendige Aufwand und das notwendige Wissen überschreitet die Fähigkeiten des typischen PHP-Coders bei weitem.

Schlechte Coder schreiben schlechten Code. Wo ist da der Bezug zur Programmiersprache?

Libraries, Frameworks, Standard-Anwendungen.

»» PHP selbst macht es einem sicherheitsbewußten Entwickler oder Administrator nicht leichter. Ich möchte nicht dafür garantieren müssen, dass ein PHP-Server so sicher konfiguriert ist, dass niemand eindringen kann. Für meine Perl-basierten Anwendungen lege ich die Hand ins Feuer.

Auf den SELFHTML-Servern läuft PHP und Perl für unterschiedliche Anwendungen. Ich habe bislang noch keinen Eindringlingszwischenfall feststellen müssen.

Ich habe nie behauptet, dass PHP grundsätzlich nicht sicher zu konfigurieren ist, und dass man in PHP keinen sicheren Code schreiben kann. Ich halte es nur für wesentlich schwieriger.

»» Der Punkt ist schlicht und ergreifend, dass Perl mir Werkzeuge gibt, Standard-Fehler zu vermeiden: warnings, strict, Taint Mode, und einen großen Satz gut geprüfter Standard-Libraries. Es versucht allerdings nicht, Standard-Fehler ungefragt durch Automatiken zu reparieren (Magic Quotes).

Der Standard-Auslieferungszustand für magic_quotes ist "aus",

Auch bei den PHP-Installationen der gängigen Hoster?

das Feature ist in Version 5.3.0 deprecated und wird in 6.0 rausgeworfen werden, weil die PHP-Entwickler erkannt haben, dass diese Automagie problematisch ist.

Wann wird 6.0 bei den Hostern angekommen und 5.x abgeschaltet sein?

Manitu hat PHP4 erst 2008 ausgeschaltet, Strato bietet PHP 4 immer noch an, ebenso 1&1.

Bei den Perl-Versionen sieht es leider nicht besser aus. 5.8 ist bei den Hostern noch nicht angekommen.

Magic Quotes für Get, Post und Cookies (magic_quotes_gpc) sind bei 1&1 EINgeschaltet, sowohl für PHP4 als auch für PHP5.

Darauf weiter herumzureiten ist also nicht hilfreich.

So lange es in der Praxis eingeschaltet ist, sollte man zumindest darauf Hinweisen, das PHP so einen Unsinn macht.

Sowas wie "Warnings" und "Strict" kriegt PHP eigentlich auch ganz gut hin, um zur Entwicklungszeit ungünstige Konstrukte anzumeckern.

"eigentlich" oder wirklich?

Die Standard-Librarys sind bei PHP entweder direkt einkompilierte Module, oder etwas aus der PEAR-Bibliothek.

Was nicht da ist, kann nicht angegriffen werden.

Und der taint mode - naja, fühlt sich auch eher wie ungute Automagie an - bei PHP war sowas ja böse... :)

Der Taint Mode versucht nicht, irgendetwas gerade zu biegen, was ein schlampiger Programmierer verbockt hat, wie es PHP mit den Magic Quotes macht. Der Taint Mode bricht die Verarbeitung mit einer Fehlermeldung komplett ab, wenn unverifizierter Input an kritische Funktionen (system, exec, open, rename, ...) weitergegeben wird, egal ob explizit (Parameter) oder implizit (%ENV). Das ist ganz ausführlich in perlsec dokumentiert und hat absolut nichts magisches an sich.

Abgesehen davon gibt es auch für PHP Erweiterungen, die die Sicherheit im laufenden Betrieb erhöhen - ich weise da nur mal auf Suhosin hin, sehr empfehlenswert.

Wer benutzt die standardmäßig?

Ist die bei den gängigen Hostern verfügbar?

Bei Manitu, Strato und 1&1 habe ich jedenfalls keinen Hinweis darauf gefunden.

»» Die Tatsache, dass Perl nicht bei jedem Hosting-Paket verfügbar ist, und nicht komplett ohne Nachdenken aktiviert werden kann, sortiert schonmal die komplett Ahnungslosen aus. Kleine Gemeinheiten einiger Hoster (Perl ist in /opt/local/perl5/bin/perl statt in /usr/bin/perl) verstärken das noch. Effekt: "Mit PHP ist das alles viel leichter und einfacher". Das sorgt dafür, dass es weniger Ahnungslose auf der Perl-Seite gibt und mehr auf der PHP-Seite. Oft setzen die Hoster alte bis antike Perl-Versionen ein, so dass nicht jedes irgendwo zusammenkopierte Perl-Script sofort läuft. Das schiebt noch mehr Leute zu PHP. Shell-Zugriff gibt es oft gar nicht, an das Error-Log kommt man nur sehr umständlich oder gar nicht heran, und wenigstens 1&1 macht mit Perl *SEHR* merkwürdige Sachen über mod_rewrite und einen selbstgestrickten Wrapper. Das sind noch mehr Hürden, die noch mehr Laien zu PHP treibt und von Perl fernhält.

Und das sind alles Dinge, die man auch als Perl-Entwickler nicht haben will, weil es ein echt blöder Extra-Aufwand ist, den man lieber mit sinnvolleren Dingen zubringen würde.

Da gebe ich Dir vollkommen recht.

»» Der für Perl-Entwickler sehr positive Effekt ist, dass sich die meisten Black Hats auf die leichten Ziele einschießen. Warum sich an Perl die Zähne ausbeißen, wenn man von Laien draufkopierte und nicht ansatzweise abgesicherte phpMyAdmin- und phpBB-Installationen in Massen übernehmen kann? Das gleiche Spiel wie bei Windows vs. MacOS/Linux und IE vs. FF/Opera.

Du meinst, es ist gut, wenn Sicherheitslücken zwar eingebaut, aber nicht ausgenutzt werden, weil sich eh' niemand dafür interessiert,

Apple hat mit exakt dieser der Argumentation tonnenweise Hardware vertickt und tut es noch heute.

weil die Sprache als obsolet betrachtet wird? :)

Eher wegen des "Millionen Fliegen können nicht irren"-Prinzips.

Alexander