AutoLoader vs. chroot

• use POSIX 'exit';
  require Carp::Heavy; # see last example
  chdir( '/tmp' );
  chroot( '/tmp' ) || die $!;
  exit(0);
  

• Can't locate auto/POSIX/exit.al in @INC
• auch Storable, Net::SSLeay, ...
• Ausweg: vorher aufrufen wenn möglich, z.B.
  eval{Storable::freeze()}

Unicode vs. chroot I

• chdir( '/tmp' );
  chroot( '/tmp' ) || die $!;
  print shift(@ARGV) =~ m/(\p{IsPrint}+)/;
  

• Can't locate utf8.pm in @INC
• Ausweg: vorher explizit laden

Unicode vs. chroot II

• # html decode: &#48 -> '0'
  chdir( '/tmp' );
  chroot( '/tmp' ) || die $!;
  $_ = shift;
  s{  &\#(\d+) }{ chr($1) }xeg;
  print m{(\w+)};
  

• test.pl 'bla&#48' -> 'bla0'
• test.pl 'bla&#480' -> 'Can't locate utf8.pm in @INC'
• Problem tritt nur mit dem richtigen Input auf
• Ausweg: vorher explizit laden, use bytes

Reaktion in CPAN Modulen

• Module erwarten im Allgemeinen korrekten Input:
  • Reaktion bei fehlerhaftem oder ambivalentem Input u.U. problematisch
  • Superlange Zeilen als Input für MIME::Parser führen zu riesenhaftem Speicherverbrauch und schließlich zum Crash.
• Deshalb nur eingeschränkter Einsatz möglich:
  • Net::DNS spricht nur mit lokalem Nameserver
  • MIME::Parser in chroot und nur an Stellen, wo ein Crash den Rest des Systems nicht gefährdet
  • Benutzen i.A. eigenen Code, insb. weil es oft auch nötig ist Ambivalenzen vor dem Weiterleiten zu entfernen (z.B. HTML)

typische Fehler

• Einlesen zeilenweise, da Input kurze Zeilen sein sollte
• Davon ausgehen, das zu jedem Block-Anfang kurze Zeit später ein Block-Ende kommen sollte (Quotes, Klammern...)
• explodierende Rekursionen (zB bei verschachteltem MIME)
• mangelndes Verständnis von Regex

Probleme mit Regex

• Regex sind mächtig
• Regex sind komplex
• sehen oft einfacher aus, als sie es sind
• im Allgemeinen nur mit Blick auf erwarteten Input entwickelt
• Können auf unerwartetem Input "explodieren", auch wenn dieses selbst für das geübte Auge nicht offensichtlich ist
• keine Möglichkeit Resourcen für Regex zu beschränken
• Leider brauchen auch die Kunden die Mächtigkeit der Regex in ACLs, können jedoch noch weniger perl

Probleme mit Regex, Beispiel 1

• Aufgabe:
  Erhöhe Spamlevel, wenn mindestens 3 Empfänger in einer To-Zeile (Addr mit Komma getrennt)

  
  # To: bla@fasel.com, me@example.org,...
  if ( $header =~m{ ^To: ([^,]+,){3,} }xim } ) {
     ...
  }
  

• Führte zu Out of memory bei 100en von Empfaengern, da versucht wird alle zu matchen.
• ein {3} statt {3,} wäre besser gewesen

Probleme mit Regex, Beispiel 2

• Aufgabe:
  Matche HTML-Tag mit Attributen.

   # <a href=... title="...".. >
   1 m{ <\w+  #Tag
   2   ( 
   3     \s+\w+   #Attribute Name
   4     ( \s*=\s* ( 
   5       "[^"]*"  # quoted Value
   6       |[^"\s]+ # unquoted
   7     )?)? # attr|attr=|attr=value
   8   )*
   9 \s*> }xs;
  

• Bei <a href=..100e spaces.. wird es exponentiell langsamer, da Regex Engine sich nicht zwischen Matches in Zeile 3 und Zeile 4 entscheiden kann.
• Lösung bestand daran nicht ganz so viel Müll zu akzeptieren

Zusammenfassung

• Vorteile
  • Hohe Produktivität
  • Schnelle Reaktionszeiten
  • Gutes Verhältnis von Code zu Funktionalität, sodaß noch Kraft für Tests und Dokumentation ist
• Nachteile
  • Sicherheitsbewusstsein bei den Maintainern sollte ausgeprägter sein
  • Schwer gute Leute zu bekommen, die wartbaren Code schreiben
  • Regex sind mächtig aber unbeherrschbar
• Wo wären wir ohne perl?
  • Maintainership von IO::Socket::SSL übernommen
  • Net::SIP (VoIP) ist seit kurzem auf CPAN

Ende