Ankündigung

Einklappen
Keine Ankündigung bisher.

Abschaltung von PHP 4/5

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #61
    Zitat von [headcrash] Beitrag anzeigen

    Das ist aber nicht wirklich erstaunlich und nicht DF anzulasten, Blogs, soziale Medien etc. werden noch weniger wahrgenommen als Newsletter von der Masse der Kunden, da hilft oft nur der harte Aufschlag (und wenn man dann noch einen Alternativplan B den Kunden anbieten kann, um so besser).
    Bei mir sieht es anders aus, ich nehme Newsletter kaum wahr. Die breite Streuung ist bei solchen Informationen wie der PHP-Abschaltung halt wichtig.

    ich bin beispielsweise kein Blogleser, sprich das DF-Blog ist für mich nicht da. Die FB-Präsenz von DF habe ich abonniert, die besteht aber leider nur noch aus Dingen die kaum was mit Hosting zu tun haben. Dort wurde beispielsweise noch gar nicht über die bevorstehenden Änderungen informiert.

    Gut finde ich ,das DF just in diesem Moment gerade die nächste Welle an Newslettern lostritt
    Markus
    ---
    https://www.facebook.com/markus.weber.180410

    Kommentar


      #62
      Hallo Markus,

      Zitat von wecotec Beitrag anzeigen
      Gut finde ich ,das DF just in diesem Moment gerade die nächste Welle an Newslettern lostritt
      Hier werden auch noch weitere Wellen folgen.
      Blog - Facebook - Twitter
      Communitybetreiber: domainfactory GmbH
      Impressum / Pflichtangaben

      Kommentar


        #63
        Zitat von wecotec Beitrag anzeigen
        Dazu hatte ich in einem anderen Thread schon geschrieben dass Ihre AGB das quasi ausschließen. Wäre mir auch neu dass das auf den Hoster zurückfällt, dann würden vor allem die kleinen Hoster dieses Risiko nicht eingehen und PHP5 noch weiter anbieten.
        Sie werden im Problemfall da ein sehr negatives Echo als Firma bekommen, egal wie Sie das ausgeschlossen haben oder es in den Tiefen der AGB steht. Wenn sie sich mal die Sicherheitsdebatten in den Medien ansehen, werden Sie sicher auch bestätigen können, dass Firmen diesbezüglich Schaden nehmen, selbst wenn es genau genommen irgendwo steht. Ein Beispiel dafür ist die Diskussion über das "Abhören"/Traqnskrepieren. Klar, völlig anders gelagert, aber man sieht hier beispielhafte Auswirkungen.

        Ich stelle nochmal die Frage: Welche Sicherheitsrisiken geht ein Hoster ein, der ältere PHP-Versionen anbietet?
        Das Gesamtsystem wird dadurch unsicher. Es ist Anforderung an unsere Systeme, dass keinerlei EOL-Software eingesetzt wird. In dieser können Sicherheitslücken entdeckt werden, die keiner mehr korrigiert. Daher ist diese für den Produktivbetrieb nicht geeignet.

        Mit freundlichen Grüßen

        Nils Dornblut
        Blog - Facebook - Twitter
        Communitybetreiber: domainfactory GmbH
        Impressum / Pflichtangaben

        Kommentar


          #64
          Zitat von wecotec Beitrag anzeigen
          Die FB-Präsenz von DF habe ich abonniert, die besteht aber leider nur noch aus Dingen die kaum was mit Hosting zu tun haben. Dort wurde beispielsweise noch gar nicht über die bevorstehenden Änderungen informiert.
          Da schaue ich mal, was wir da machen können.

          Mit freundlichen Grüßen

          Nils Dornblut

          Blog - Facebook - Twitter
          Communitybetreiber: domainfactory GmbH
          Impressum / Pflichtangaben

          Kommentar


            #65


            Zitat von Nils Dornblut Beitrag anzeigen
            Das Gesamtsystem wird dadurch unsicher. Es ist Anforderung an unsere Systeme, dass keinerlei EOL-Software eingesetzt wird. In dieser können Sicherheitslücken entdeckt werden, die keiner mehr korrigiert. Daher ist diese für den Produktivbetrieb nicht geeignet.
            Erstmal danke dass Sie versuchen diese Frage zu beantworten, das weiss ich sehr zu schätzen....der Kollege Kaufmann hat sich das ja nicht getraut

            Die Argumente sind ja soweit bekannt und auch logisch. Interessant finde ich, dass kein Fall bisher bekannt ist, dass ein Systemeinbruch über PHP direkt passiert ist. Und selbst für PHP 5.6 kommen jetzt noch Updates, vermutlich aufgrund seines Verbreitungsgrades. Mein alter Hoster hatte direkte Kontakte ins PHP-Team, wie sieht es bei DF aus? Wie gut ist DF mit den Teams der eingesetzten Software vernetzt?

            Wenn Sie es wirklich schaffen keinerlei EOL-Software einzusetzen ist das eine tolle Leistung....nur umgekehrt muss dann neue Software (z.b. mysql 5.7) sehr zeitnah verfügbar sein (Beispiel: durch die späte Einführung von PHP 7 hängen wir bei einigen Updates tatsächlich noch bei PHP 5.6....die werden hier jetzt aus Zeitgründen weggezogen, da wir die PHP 7-Updates priorisieren müssen) . Wie wird verfahren wenn der Fall eintritt dass Komponente A EOL ist, aber Komponente B noch nicht verfügbar ist und beide für ein populäres CMS benötigt werden? Wie sieht hier der Plan bei DF aus?

            Ich bin der ganzen Sache nicht abgeneigt. Nur muss DF erstmal liefern (Stichwort neues Image) und bei Neueinführungen nicht hinterherhinken. Dann kann das Thema Update bei EOL geschmeidig und ohne Kundenärger laufen
            Markus
            ---
            https://www.facebook.com/markus.weber.180410

            Kommentar


              #66
              Zitat von wecotec Beitrag anzeigen
              Die Argumente sind ja soweit bekannt und auch logisch. Interessant finde ich, dass kein Fall bisher bekannt ist, dass ein Systemeinbruch über PHP direkt passiert ist.
              Ich kann jetzt nicht zuordnen, woraus die Informationen beruht. Sicherheitsrelevante Probleme gab es auch bei PHP und seinen Modulen schon einige. Ist aber auch denke ich ziemlich egal, wo die im Detail lagen.

              Und selbst für PHP 5.6 kommen jetzt noch Updates, vermutlich aufgrund seines Verbreitungsgrades.
              Das mag alles sein, aber warum wird denn dann ein EOL vom Hersteller definiert, wenn es alles sicher ist?

              Mein alter Hoster hatte direkte Kontakte ins PHP-Team, wie sieht es bei DF aus? Wie gut ist DF mit den Teams der eingesetzten Software vernetzt?
              Allein durch die Firmengröße sind wir ziemlich gut vernetzt. Was soll das aber in diesem Fall bringen. "Problem" ist nicht fehlender Kontakt, sondern die Erklärung des EOL vom Hersteller und der wird sicher auch dort heiß diskutiert und nicht leichtfertig mal eben so festgelegt.

              Wenn Sie es wirklich schaffen keinerlei EOL-Software einzusetzen ist das eine tolle Leistung....nur umgekehrt muss dann neue Software (z.b. mysql 5.7) sehr zeitnah verfügbar sein (Beispiel: durch die späte Einführung von PHP 7 hängen wir bei einigen Updates tatsächlich noch bei PHP 5.6....die werden hier jetzt aus Zeitgründen weggezogen, da wir die PHP 7-Updates priorisieren müssen) . Wie wird verfahren wenn der Fall eintritt dass Komponente A EOL ist, aber Komponente B noch nicht verfügbar ist und beide für ein populäres CMS benötigt werden? Wie sieht hier der Plan bei DF aus?
              Wir werden zukünftig die sicherst mögliche Variante wählen und die Schwierigkeiten sind ja wenn dann allgemein in der Branche vorhanden bzw. werden auch von den jeweiligen Herstellern erkannt. Ich würde mal behaupten, dass sich das in nahezu jedem Fall schnell regeln wird oder adäquate Alternativen ansonsten vorhanden sind.

              PHP 7 haben wir am Geburtstag meiner Tochter eingeführt. Sie kam kürzlich in den Kindergarten. Etwas Zeit ist diesbezüglich also schon vergangen

              Mit freundlichen Grüßen

              Nils Dornblut



              Blog - Facebook - Twitter
              Communitybetreiber: domainfactory GmbH
              Impressum / Pflichtangaben

              Kommentar


                #67
                Laut Info ist auch PHP 7.0 und 7.1 betroffen:

                Beachten Sie bitte, dass wir die Unterstützung der PHP Versionen 4, 5, 7.0, 7.1 einstellen werden.
                Ab 02.12.2019 werden die Versionen 4 nicht mehr von uns unterstützt.
                Ab 02.03.2020 werden die PHP-Versionen 5 und NEU 7.0 und 7.1 nicht mehr von uns unterstützt.
                Bis dahin können Sie die betroffenen Versionen weiter nutzen.

                In der Auftragsübersicht, Gesamtübersicht und in den PHP-Einstellungen sind Ihre betroffenen Domains rot hinterlegt.
                Leider können wir manche Anwendungen nicht auf 7.2 oder gar 7.3 hochdrehen. Kann daher nicht 7.0 oder 7.1 weiter supported werden? Andere Anbieter wie ********* schaffen es doch auch, beispielsweise derzeit "5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3" anzubieten.
                Zuletzt geändert von Nils Dornblut; 25.11.2019, 23:06. Grund: Bitte keine Fremdanbieter nennen

                Kommentar


                  #68
                  Zitat von raymond Beitrag anzeigen
                  Leider können wir manche Anwendungen nicht auf 7.2 oder gar 7.3 hochdrehen. Kann daher nicht 7.0 oder 7.1 weiter supported werden? Andere Anbieter wie ***** schaffen es doch auch, beispielsweise derzeit "5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3" anzubieten.
                  Vorsicht bei der Nennung von anderen Anbietern, das ist hier nicht gerne gesehen.....

                  Es schafft fast jeder Anbieter, und inzwischen wette ich, dass DF es auch tun wird.....aber drauf verlassen würde ich mich nicht und mir schon einen Plan B (Wechsel des Anbieters) überlegen.
                  Zuletzt geändert von Nils Dornblut; 25.11.2019, 23:07. Grund: Fremdanbieter entfernt
                  Markus
                  ---
                  https://www.facebook.com/markus.weber.180410

                  Kommentar


                    #69
                    Zitat von wecotec Beitrag anzeigen
                    Es schafft fast jeder Anbieter, und inzwischen wette ich, dass DF es auch tun wird.....aber drauf verlassen würde ich mich nicht und mir schon einen Plan B (Wechsel des Anbieters) überlegen.
                    Fast jeder Anbieter ist wohl übertrieben. Alle Webhoster (10+), wo wir Kunde sind, hat bereits die alten PHP Versionen abgekündigt oder die Frist ist bekannt. Der Tag "X" wird kommen früher oder später. Auch später bei den anderen Marktbegeleitern von dF. Falls eine ernstzunehme Sicherheitslücke in den Version 4/5 gefunden wird, eher früher (morgen). Und dann wird vermutlich der Aufschrei noch größer sein? Mit der DSGVO hat man eigentlich noch ein zusätzliches Druckmittel zur Hand. Denn PHP 4/5 entsprechen defintiv nicht mehr der "Stand der Technik". Damit bekommt man fast jeden Vorgesetzten zur Zustimmung.

                    Kommentar


                      #70
                      Zitat von Schakal Beitrag anzeigen
                      Falls eine ernstzunehme Sicherheitslücke in den Version 4/5 gefunden wird, eher früher (morgen). .
                      Zitat meines Alternativ-Hosters: "Die wirklich ernsten Lücken existieren auch in PHP 7.3". Dieses Zitat stammt vom von einem Techniker der 20 Jahre mit Hosting zu tun hat.

                      Bitte nicht falsch verstehen, ich bin auch kein Freund von veralteter PHP-Software. Aber es gibt Konstellationen wo es nicht anders geht. Und da muss ganz einfach empfehlen dass man den Hoster wechselt.

                      Und selbst in PHP4 sind keine Lücken bekannt....ich denke das soll was heissen. Die Lücken entstehen eher durch Software, die nicht mehr für die entsprechende PHP-Version gepflegt werden. Und genau hier liegt das "Problem".

                      Technisch hat DF absolut Recht PHP 4/5/7.0/7.1 zu deaktivieren. Aber man sieht ja jetzt schon an der Verschiebung der PHP7-Deaktivierung dass es in der Realität anders läuft als die Technik es sich wünscht.
                      Zuletzt geändert von wecotec; 25.11.2019, 23:05.
                      Markus
                      ---
                      https://www.facebook.com/markus.weber.180410

                      Kommentar


                        #71
                        Zitat von raymond Beitrag anzeigen
                        Laut Info ist auch PHP 7.0 und 7.1 betroffen:



                        Leider können wir manche Anwendungen nicht auf 7.2 oder gar 7.3 hochdrehen. Kann daher nicht 7.0 oder 7.1 weiter supported werden? Andere Anbieter wie ********* schaffen es doch auch, beispielsweise derzeit "5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3" anzubieten.
                        Es ist keine Frage des Schaffens, sondern eine Frage der Sicherheit. Wir möchten zukünftig keine Software mehr betreiben die das "End of Life" laut deren Herstellern erreicht hat und nicht mehr offiziell mit Updates versorgt wird. Wir halten das in der heutigen Zeit für den einzigen Weg eine dauerhaft stabile Plattform bereitzustellen und den Sicherheitsanforderungen zu entsprechen. Wenn andere dieses garantieren möchten und können oder das Risiko auf den Kunden abwälzen möchten und dieser das akzeptiert, dann sind andere Varianten denkbar. Generell treffen aber nicht wir die Entscheidung wie lange z. B. PHP in der Version genutzt werden kann, sondern der Produzent der Software. Dies in der Annahme, dass er das auch am besten einschätzen kann. Natürlich kann man diesem die Frage stellen warum es das so handhabt, das können wir aber nicht erschöpfend beantworten und müssen leider verweisen.

                        Mit freundlichen Grüßen

                        Nils Dornblut
                        Blog - Facebook - Twitter
                        Communitybetreiber: domainfactory GmbH
                        Impressum / Pflichtangaben

                        Kommentar


                          #72
                          Zitat von wecotec Beitrag anzeigen
                          Zitat meines Alternativ-Hosters: "Die wirklich ernsten Lücken existieren auch in PHP 7.3". Dieses Zitat stammt vom von einem Techniker der 20 Jahre mit Hosting zu tun hat.
                          Und ist durch was belegt? Wenn es Lücken in aktueller Software gibt, die ausgenutzt werden können, dann werden die primär dort behoben und getestet. Diesbezüglich wäre ich gespannt auf gegenteilige Fakten.

                          Bitte nicht falsch verstehen, ich bin auch kein Freund von veralteter PHP-Software. Aber es gibt Konstellationen wo es nicht anders geht. Und da muss ganz einfach empfehlen dass man den Hoster wechselt.
                          Entschuldigen Sie bitte, aber das ist nicht richtig in meinen Augen. Sie schieben damit nur das Problem vor sich her und lösen es nicht. Klar, es kann theoretisch Fälle geben, wo eine Lösung mehr Zeit braucht, aber das erlebe zumindest ich sehr selten. Es geht meist eher darum, dass Kunden für entsprechende Anpassungen nicht zahlen möchten oder keine Kapazitäten beim Dienstleister vorhanden sind (qualitativ/quantitativ).

                          Mit freundlichen Grüßen

                          Nils Dornblut
                          Blog - Facebook - Twitter
                          Communitybetreiber: domainfactory GmbH
                          Impressum / Pflichtangaben

                          Kommentar


                            #73
                            Zitat von Nils Dornblut Beitrag anzeigen
                            Und ist durch was belegt? Wenn es Lücken in aktueller Software gibt, die ausgenutzt werden können, dann werden die primär dort behoben und getestet. Diesbezüglich wäre ich gespannt auf gegenteilige Fakten.
                            Mich hat diese Aussage genauso überrascht wie Sie Ich werde da bei Gelegenheit nachfragen!

                            Zitat von Nils Dornblut Beitrag anzeigen
                            Entschuldigen Sie bitte, aber das ist nicht richtig in meinen Augen. Sie schieben damit nur das Problem vor sich her und lösen es nicht. Klar, es kann theoretisch Fälle geben, wo eine Lösung mehr Zeit braucht, aber das erlebe zumindest ich sehr selten. Es geht meist eher darum, dass Kunden für entsprechende Anpassungen nicht zahlen möchten oder keine Kapazitäten beim Dienstleister vorhanden sind (qualitativ/quantitativ).
                            Richtig, es lassen sich viele Probleme irgendwie lösen. Es gibt aber auch Fälle wo Software neu geschrieben werden müsste weil der Programmierer nicht mehr greifbar ist. Das zieht sich von individueller Software bis bis in Plugins von aktuellen CM-Systemen. Klar, mit genug Wille und Geld lassen sich diese Probleme lösen.

                            Da kann man den Kunden aber keinen Vorwurf machen. Es ist ähnlich wie bei DF: Wenn nicht genug Resourcen & Wille da sind geht es einfach nicht. Bei DF ist es doch eigentlich noch schlimmer: Trotz einer grossen Mutter im Rücken (=Resourcen) schafft man es nicht essentielle Features wie z.B. aktuelles mySQL bereit zu stellen.

                            Auf der einen Seite verlangt man von seinen Kunden Kraftakte zu vollbringen, auf der anderen Seite schafft man es nicht zu liefern um aktuelle Software einsetzen zu können.
                            Zuletzt geändert von wecotec; 26.11.2019, 07:42.
                            Markus
                            ---
                            https://www.facebook.com/markus.weber.180410

                            Kommentar


                              #74
                              Zitat von wecotec Beitrag anzeigen
                              Zitat meines Alternativ-Hosters: "Die wirklich ernsten Lücken existieren auch in PHP 7.3". Dieses Zitat stammt vom von einem Techniker der 20 Jahre mit Hosting zu tun hat.
                              Durchaus und die Welt hat sich diesbezüglich in den letzten 10 Jahren verändert - keine Frage. Um so größer die Verbereitung von Sofware ohne Support durch den Hersteller ist, um größer ist dies ein Magnet für Hacker. Unterhalte dich mal diesbezüglich mal mit erfahrenen Pentester. Inzwischen sehe ich da parallelen mit der Steuerungen in der Fertigungsstraßen in der Industrie. Dort wird auch aus Kostengründen die Software 10-15-20 Jahre! eingesetzt, weil ein Upgrade z.B. für eine kl. CNC-Maschine ein haufen Geld kostet.

                              Zitat von wecotec Beitrag anzeigen
                              Bitte nicht falsch verstehen, ich bin auch kein Freund von veralteter PHP-Software. Aber es gibt Konstellationen wo es nicht anders geht. Und da muss ganz einfach empfehlen dass man den Hoster wechselt.
                              Grundsätzlich bin ich der Meinung, dass es keine Konstellationen gibt, die nicht lösbar sind. Die Frage wird sein, welche Kosten dafür entstehen. In Deutschland ist es leider so, dass es erst richtig weh tun und/oder der eigene Arsch in der direkten Schlusslinie stehen muss. Danach stehen meistens für Themen Sicherheit und Upgrade die notwendigen Mittel zur Verfügung. Spätestens wenn der Hoster die Version abschaltet, geht das Spiel von vorne los. Was gewinnst du dadurch? Zeit, ist es nicht...

                              Zitat von wecotec Beitrag anzeigen
                              Und selbst in PHP4 sind keine Lücken bekannt....ich denke das soll was heissen. Die Lücken entstehen eher durch Software, die nicht mehr für die entsprechende PHP-Version gepflegt werden. Und genau hier liegt das "Problem".
                              Nicht bekannt heißt nicht automatisch das es keine gibt. Das gilt nicht nur für PHP sondern aus meiner Sicht immer - egal ob Open oder Closed Source. Das ist deine Aufgabe Lösungen aufzuzeigen und deren Vor/nachteile zu nennen. Dafür bist du doch da.

                              Zitat von wecotec Beitrag anzeigen
                              Technisch hat DF absolut Recht PHP 4/5/7.0/7.1 zu deaktivieren. Aber man sieht ja jetzt schon an der Verschiebung der PHP7-Deaktivierung dass es in der Realität anders läuft als die Technik es sich wünscht.
                              dF hat meiner Ansicht nach die rechtzeitige Planung/Ankündigung verpasst. Ich gehe davon aus, dass dies u.a. mit dem Vorfall letztes Jahr verbunden ist, welcher zu lange zu viele Ressourcen gebunden hat. Das geht mir jede Woche so, dass Projekte/Themen verschoben oder pausiert werden. Personal- und Zeitressourcen sind nun mal begerenzt und daher werden Prioritäten gesetzt und auch mal geändert.


                              /Dani

                              Kommentar


                                #75
                                Zitat von wecotec Beitrag anzeigen
                                Aber man sieht ja jetzt schon an der Verschiebung der PHP7-Deaktivierung dass es in der Realität anders läuft als die Technik es sich wünscht.
                                Ersetze Technik durch irgendwelche Entscheider und es sollte passen und ich gehe davon aus, dass es da interne Diskussionen gab, ob der blitzartige Terminplan jetzt wirklich so clever war oder man da etwas den Druck rausnimmt.

                                Kommentar

                                Lädt...
                                X