PHP 5.6 nervt! Die Verwendung der mysql-Erweiterung wirft Fehler. Okay, die Meldungen lassen sich wegkonfigurieren – ist aber wie immer eine eher bloede Idee als dauerhafte Loesung 😉 Vor allem, wenn die Software, welche „am Leben“ erhalten werden muss, auch keinen Support mehr hat. So etwa TGPX. Einstmals von JBSoft entwickelt, vor etwa zwei Jahren dann aber public domain gemacht und den Support eingestellt. Was tun, wenn Kunde™ zig Seiten darunter betreibt und sich einfach keine bessere Loesung finden laesst 🙁 Da hilft nur: Selber fixen. In dem Fall sogar recht einfach uebers Umstellen auf mysqli zu loesen. Okay, habe es mir einfach gemacht und schlicht die schon vorhandene mysql-Class hart erweitert/umgestellt. Dadurch ist das „Upgrade“ aber auch ganz einfach. Es muss lediglich die Datei „mysql.class.php“ im includes-Verzeichnis ausgetauscht werden. Warnung: Ich habe mir den Rest der Software nicht angesehen. Von der Klasse selbst her, scheint das alles schoen sauber oder zumindest vertretbar ausgereift. Garantieren kann ich das nicht. Nur feststellen, dass die Seite meines Kunden jetzt wieder funktioniert 🙂 Und wo gibt es den Patch?
https://github.com/3UU/TGPX/blob/master/includes/mysql.class.php
Weil ich gerade dabei bin, mich ueber seltsame Dinge aufzuregen: Wenn jemand die Entwicklung seiner Software aus welchen Gruenden auch immer einstellt, darf ihm niemand vorwerfen, falls diese nach irgendwelchen Systemupdates nicht mehr funktioniert. Wenn jemand aber die Funktionalitaet von Software ohne zwingenden Grund aendert, dann gehoert er/sie dafuer eigentlich gehauen. Es sei denn, es ist nen Masochist 😉 Was die Entwickler von PHP sind, weiss ich nicht. Auf jeden Fall betteln sie mit dem Umbau der Remote-Funktionen fuer den verschluesselten Aufruf von Seiten geradezu nach Haue. Neuerdings schlaegt der naemlich fehl, wenn das Zertifikat nicht „verifiziert“ werden kann. Was vorgeblich eine Massnahme gegen Man-in-the-middle-Angriffe sein soll, zerschiesst so manche Software, die bislang auch ganz gut ohne Verifizierung auskam. Nein, ich bin nicht der Meinung, dass jeder Pfurtz verschluesselt und signiert sein muss!
Wer wirklich sichere Software schreiben will, wird ohnehin nicht dieses unsaegliche Sammelsurium von Root-CAs akzeptieren wollen. Ohne zusaetzliche Absicherung mit DNSSEC und DANE waere das ziemlich bloed. Und sogar dann ist nicht sicher, dass die CA nicht von irgend einem Uebelwicht kompromittiert wurde. Vielleicht sogar mittels Maulkorb-Beschluss gezwungen wurde, Zweitzertifikate fuer den Angriff auszustellen… Dagegen hilft nur die Verwendung und Einschraenkung auf die eigene CA. Alles andere ist broken by design! Interessiert die PHP-Goetter aber nicht. Also was soll’s, bauen wir halt die ueblichen Root-CAs in die Konfiguration ein. Einfach die „php.ini“ um folgendes ergaenzen
openssl.cafile=/usr/local/etc/openssl/cert.pem
wobei die „cert.pem“ natuerlich entsprechend aktuell sein sollte. Auch die Entwickler von CURL – die wohl am meisten davon betroffenen Funktionen in PHP – haben das Problem erkannt und stellen unter http://curl.haxx.se/docs/caextract.html eine entsprechendes PEM-File zur Verfuegung.