Debian 10 mit PHP 7.0

[AxelMahle]

Ist es möglich Debian 10 nicht mit PHP 7.3 sondern mit PHP 7.0 zu installieren?

[DeletedUserReAsG]

Könnte man nachträglich machen, indem man sich die Sourcen lädt, es baut, und etwa nach /opt/ installiert, oder sich ein Paket baut.

Allerdings: die Version wird vom Upstream nicht mehr supportet, Sicherheitslücken existieren und können ausgenutzt werden.

[uname]

Warum willst du PHP 7.0 verwenden? Wäre wohl sinnvoller die PHP-Programme zu aktualisieren. Welches PHP-Software ist betroffen? Wo laufen die PHP-Programme auf Fehler?

[AxelMahle]

Wir setzen einen Onlineshop ein der ist nicht für 7.3 freigegeben. Der Hersteller sagt unter 7.3 gibt massive Probleme.

[uname]

Wahrscheinlich wäre es sinnvoller gewesen bzw. ist es sinnvoller weiterhin bei Debian Stretch zu bleiben. Ich hoffe mal der Shop läuft noch mit Debian Stretch und ist nicht durch ein Upgrade aktuell offline
Debian Stretch hat Support bis 2020 bzw. LTS bis 2022. Da bleibt noch einiges an Zeit, dass der Hersteller die PHP-Probleme löst.
Niemand muss jetzt von Debian Stretch auf Debian Buster wechseln. Vor allen auf Serversystemen ist es normal, dass es mal etwas länger dauert. Genau dafür gibt es ein Jahr OldStable und zusätzlich noch LTS.

[DeletedUserReAsG]

Das Problem ist halt, dass PHP 7.0 von Hersteller nicht mehr gepflegt wird. Damit auch nur irgendwas zu betreiben, das am Netz hängt, ist fahrlässig. Wenn’s dann noch was ist, wo sensible Daten (Kunden-/Zahlungsdaten) drüber laufen, ist’s schon schlimm.

Wenn der Hersteller der Shopsoftware es in 1½ Jahren nicht schafft, seinen Kram zu reparieren, dann würde ich mir zunächst ’ne andere Shopsoftware suchen. Vermutlich liegen dann nämlich auch noch andere Dinge im Argen. Ich hab die Erfahrung selbst machen dürfen: Chef einer kleinen Firma kauft tolle Shopsoftware, anschließend stellt sich raus: ist ein umgelabeltes OSS-Projekt. Fixes kamen, wenn der Upstream des Projektes sie fertig hatte, und später kam nicht mal das – entsprechend lief’s auch nicht mehr mit neueren PHP-Versionen. Und bekannte Fehler in ’ner exponierten Webanwendung, die zudem noch mit ’ner seit langem nicht mehr gepflegten PHP-Version läuft, ist so ziemlich der schlimmste Fall, der überhaupt eintreten kann. Das kann richtig teuer werden, für den Betreiber.

[AxelMahle]

Laut Hersteller des Shops wäre 7.2 möglich. Wäre das eine Lösung und wenn ja wie installieren ich dann diese PHP Version parallel zur 7.3er?

[KBDCALLS]

Haken an der Sache wäre das php 7.1 und 7.2 nur noch als snapshot zu finden sind. Die dann auch noch total veraltet sind.

• Code: Alles auswählen

  rmadison php
  php        | 1:7.0+49      | oldstable  | all
  php        | 2:7.3+69      | stable     | all
  php        | 2:7.3+69      | testing    | all
  php        | 2:7.3+69      | unstable   | all

Aktuell sind 7.2.21 und 7.1.31.

[getphp]

Die Lösung ist: php in gewünschter Version von https://deb.sury.org/ installieren.

[Lord_Carlos]

Docker waere vielleicht auch eine loesung?

[uname]

Ist denn PHP 7.0 in den Paketquellen von Debian Stretch ein Sicherheitsrisiko?
https://packages.debian.org/stretch/php7.0

[eggy]

Sieh selbst:
https://www.cvedetails.com/vulnerabilit ... 7.0.0.html

Schauen wir uns nur mal die beiden 10er an:

Code: Alles auswählen

CVE-2015-8880 				2016-05-21 	2016-05-24 	10.0
	None 	Remote 	Low 	Not required 	Complete 	Complete 	Complete
Double free vulnerability in the format printer in PHP 7.x before 7.0.1 allows remote attackers to have an unspecified impact by triggering an error.

Remote und low complexity ... da freut sich jeder Angreifer.
Übersetzt: "jemand gibt Text in Deine Webseite ein, und Dir fliegt der Server um die Ohren - wie weit er fliegt, kann man nicht sagen"

Code: Alles auswählen

CVE-2016-2554 	119 		DoS Overflow 	2016-05-16 	2018-01-04 	10.0
	None 	Remote 	Low 	Not required 	Complete 	Complete 	Complete
Stack-based buffer overflow in ext/phar/tar.c in PHP before 5.5.32, 5.6.x before 5.6.18, and 7.x before 7.0.3 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted TAR archive. 

Übersetzt: "Deine Software erlaubt TAR-Archive? Wunderbar. Eine neue Methode den Server anzuhalten. Oder ihn Dir um die Ohren fliegen zu lassen, nix genaues weis man nicht" und wieder remove und low complexity.

Die anderen klingen auch nicht so als wenn man sowas auf der Kiste haben will:

Code: Alles auswählen

before 7.1.3, remote attackers could cause a CPU consumption denial of service attack by injecting long form variables, related to main/php_variables.c. 
before 7.0.6 allows remote attackers to execute arbitrary code via a crafted index. 

execute arbitrary code.

@AxelMahle
Was würdest Du Deinem Currywurstfritzen erzählen, wenn er das ungekühlte Hack von letzter Woche ins Tatar mischt?

Aber bei Software mit Kundendaten gilt ja immer die Devise "wird schon nix passieren" - bis dann das Geschrei groß ist.

[uname]

Nun muss ich noch mal nachfragen. Gilt das auch für
https://packages.debian.org/de/stretch/ ... mod-php7.0

Soll das bedeuten, dass sämtliche Stretch-Installationen die Apache2 mit PHP 7.0 (Standardinstallation) nutzen, unsicher sind?
Ich wundere mich, dass noch niemand hier im Forum geschrieben hat, dass daher bei der Konstallation zwingend ein Dist-Upgrade auf Buster notwendig sei.

[DeletedUserReAsG]

Nun muss ich noch mal nachfragen.

Du könntest nun ins Debian-Changelog schauen, und mit den CVE für die Upstream-Version vergleichen. Sind alle erfasst worden: alles gut. Wenn nicht, dann muss man halt schauen. Die letzten Änderungen im Debian-Changelog sind vom März diesen Jahres. Ein mögliches Problem: dadurch, dass 7.0 obsolet ist, werden neu gefundene Lücken nicht mehr veröffentlicht und auch nicht behoben.

[uname]

Alles schön.
Aber wird nun davon abgeraten die OldStable-Version, die noch ein Jahr und anschließend per LTS noch weitere zwei Jahre supportet und angeblich mit Sicherheitsupdates versorgt wird, nicht mehr für diesen Zweck zu verwenden? Warum wird nicht davor gewarnt? Warum werden die Pakete nicht einfach rausgeworfen, damit es schlicht nicht mehr funktioniert bzw. mindestens Neuinstallationen fehlschlagen.

[DeletedUserReAsG]

Aber wird nun davon abgeraten die OldStable-Version, die noch ein Jahr und anschließend per LTS noch weitere zwei Jahre supportet und angeblich mit Sicherheitsupdates versorgt wird, nicht mehr für diesen Zweck zu verwenden?

Warum erwartest du, dass jemand anderes nun für dich nachsieht? Ich habe doch genannt, wo du schauen kannst. Zumindest mich interessiert’s nicht ausreichend, als dass ich da Zeit reinstecken wollte. Das kann gerne jemand machen, den’s interessiert.

Edit: https://security-tracker.debian.org/tra ... age/php7.0 ← entscheide selbst.

[uname]

Ich hatte nur gedacht, dass man versucht für die Pakete, die im Repository enthalten sind über den Release-Zeitraum die Security-Patches einzubrigen. Nun bin ich etwas enttäuscht. Aber alles klar.

[DerChris]

debian-security-support wäre vielleicht noch eine Quelle.

[eggy]

Ich hatte nur gedacht, dass man versucht für die Pakete, die im Repository enthalten sind über den Release-Zeitraum die Security-Patches einzubrigen. Nun bin ich etwas enttäuscht. Aber alles klar.

Wenn sich an der Codebasis nicht viel geändert hat, ist es für die Maintainer manchmal relativ leicht zu sehen, wie man nen Patch der für Version x.y geschrieben wurde, zur Vorversion oder weiter zurückportiert. Manchmal wirds aber zu komplex, weil nicht klar ist, welcher Code zu neuen Features und welcher zum Fix gehört, und ob die irgendwie verschränkt sind. Und dann gibts noch die Fälle, wo während man den Patch für Lücke a zurückportiert, schon der für Lücke b anrollt und Lücke c auch schon am Horizont zu sehen ist und man ahnt, toll morgen sitz ich wieder da ... da sagt man dann auch irgendwann, das verbrennt nur unnötig Zeit. Zeit die anderswo besser genutzt werden könnte.