PHPGangsta - Der praktische PHP Blog

[EDIT] Tja, da schreibt man gerade drüber und ein paar Minuten später wird die Lücke veröffentlicht: Poodle . Details im Google Blog. Das Problem liegt im SSLv3 Protokoll selbst, es wird keine Patches geben, es muss ausgeschaltet werden. Eigentlich wäre nur uralt-Software wie der IE6 unter WindowsXP betroffen, aber durch Downgrade-Attacken die bei TLS möglich sind, sind alle betroffen und können auf das schwache SSLv3 downgegraded werden wenn es denn auf Server+Client unterstützt wird. Also abschalten!

Seit 2 Tagen gibt es Gerüchte über eine kritische Lücke in SSLv3. Aktuell (Mitternacht) ist noch nichts publik geworden außer ein eventuell interessanter Patch von Microsoft, und eine Falschmeldung eines OpenBSD-Patches, der in Wirklichkeit schon einige Monate alt ist.

Sicher ist dass SSLv3 18 Jahr alt ist, und vor 15 Jahren durch TLSv1.0 abgelöst wurde. Bei mail.de haben wir SSLv3 bereits vor einigen Monaten deaktiviert auf den Webseiten da kaum ein Client dieses alte Protokoll benutzte außer der IE6 auf WindowsXP Systemen. Da wir den IE6 eh schon lange nicht mehr unterstützen war es sehr einfach, SSLv3 abzuschalten.

Für die anderen Protokolle wie IMAP, POP3 und SMTP haben wir SSLv3 allerdings noch aktiviert gelassen da es noch diverse E-Mail-Clients gibt die TLS >1.0 noch nicht beherrschen. Auch einige ältere Smartphones beherrschen noch kein TLS1.0 oder neuer, sodass es Sinn machte es noch aktiviert zu lassen, denn es gab auch (noch) keine bekannten Angriffsvektoren.

Weiterlesen »

Vorgestern begann eine interessante Diskussion inklusive eines RFC in der PHP-Internals-Mailingliste, in der es um die Abschaffung zweier alter und selten genutzter Möglichkeiten geht, PHP-Code als solchen zu markieren. Normalerweise beginnt PHP-Code mit <?php oder <?

Es gibt aber weitere Möglichkeiten für diesen Einsatzzweck:

<script language="php">
    echo 'Hallo';
</script>

<% echo 'Hallo'; %>

Nun ist die Frage: Soll bzw. kann man diese alternativen Tags aus der PHP-Engine entfernen? Ein Gegenargument wäre dass durch die Entfernung plötzlich der PHP-Quelltext an den Browser ausgegeben würde, ein Besucher der Webseite würde also den möglicherweise geheimen Sourcecode mit Passwörtern usw. zu Gesicht bekommen. Ist das eine reelle Gefahr die die Abschaffung für immer oder mindestens lange Zeit verhindert? Oder betrifft das nur ein paar hundert weltweit genutzte kleine Webseiten, auf die man keine Rücksicht nehmen kann?

Welche Vorteile hätte eine Entfernung, bringt es neben dem verringerten PHP-Engine-Code auch kleine Performancevorteile oder ähnliches?

In welcher Version sollte man diese Tags als DEPRECATED markieren, um so die Admins auf die nahende Entfernung hinzuweisen? Wie viele Admins oder Programmierer bekommen die DEPRECATED-Meldungen im Error-Log überhaupt mit?

Wer von euch nutzt diese ungewöhnlichen Methoden in seinem Code oder hat ihn bereits in Fremdcode oder Bibliotheken gesehen? Ich muss zugeben dass ich von den beiden Möglichkeiten in den letzten 10 Jahren nichts gehört habe und nicht wußte dass sie existieren, und sie demnach auch noch nie irgendwo gesehen habe…

Vor ziemlich genau einer Stunde ist PHP 5.6 final erschienen, und es ist Zeit sich die neuen Features und Vorteile anzuschauen. Aus meiner Sicht lohnt ein Upgrade, allein schon wegen der geschenkten 10% Performance gegenüber PHP 5.5.

Die neue Version kann auf der Downloads-Seite von php.net heruntergeladen werden. Die neuen Features sind die folgenden:
Weiterlesen »

Gerade eben ist der vierte (und letzte?) Release-Candidate von PHP 5.6.0 erschienen: PHP 5.6.0 RC4. Damit wir ein möglichst stabiles und fehlerfreies PHP haben auf allen Systemen ist jeder aufgerufen, die Testsuite durchlaufen zu lassen. Das geht sehr schnell und ohne viel Aufwand:

wget http://downloads.php.net/tyrael/php-5.6.0RC4.tar.gz
tar -xzvf php-5.6.0RC4.tar.gz
cd php-5.6.0RC4
./configure --prefix=/usr/local/php5.6.0rc4 --with-zlib --with-config-file-path=/usr/local/php5.6.0rc4/etc --enable-mbstring --enable-zip --with-imap --with-kerberos --with-imap-ssl --with-openssl --with-jpeg-dir --with-gd --with-gettext --with-freetype-dir
make
make test

Der configure Aufruf ist nur ein Beispiel, ihr müßt natürlich dort die Extensions und Optionen nehmen die eure PHP-Installation benötigt, also wahrscheinlich mit Apache-Anbindung (–with-apxs2) usw.

Solltet ihr den folgenden Fehler bekommen:

configure: error: xml2-config not found. Please check your libxml2 installation.

behebt ihr das einfach mit der Installation des libxml2-dev Pakets:

sudo apt-get install libxml2-dev

Am Ende des Durchlaufs der über 10.000 Tests erhaltet ihr dann das Ergebnis, entweder es gab Fehler oder es gab keine. Im ersten Fall könnt ihr den Fehlerbericht direkt an das QA-Team schicken indem ihr Y drückt und eure E-Mail-Adresse eingebt zwecks eventueller Rückfragen. Eine Liste aller fehlgeschlagenen Tests von allen Testern gibt es auf qa.php.net.

Danach kann das Verzeichnis einfach wieder gelöscht werden. Oder noch besser auf einem Testsystem mittels

sudo make install

richtig installieren und eure Applikation testen! Aber passt auf dass ihr dadurch nicht eine laufende PHP-Installation überschreibt und zerstört. Bis zum „make test“ macht ihr nichts kaputt.

Danke!

Ich habe soeben die 6 Abos ausgelost, die aus der Verlosung von vorletzter Woche stammen. 3 Mal das PHP-Magazin und 3 Mal das Entwickler-Magazin, für jeweils 1 Jahr. Insgesamt haben 25 Kommentare an der Verlosung teilgenommen, 18 Mal für das PHP-Magazin und 8 Mal für das Entwickler-Magazin. An diesen Zahlen sieht man schon dass einer für beides gleichzeitig teilgenommen hat, was ja nicht erlaubt war. Den musste ich streichen.
Ich musste außerdem einen Kommentar, der doppelt vorkam, entfernen (es lag anscheinend an technischen Problemen da der Text fast identisch ist, da wollte keiner betrügen nehme ich an).

Und hier sind die Gewinner:

Weiterlesen »