Bonjour Nal,
C'est aujourd'hui que le support de sécurité de PHP 7.4 touche à sa fin, mettant ainsi définitivement fin au support de la branche 7 de PHP.
Désormais, ne seront supportées que les versions 8.0 (support de sécurité seulement, et pour encore 1 an : le support actif ayant pris fin avant-hier) et 8.1 (version actuelle).
Vous pouvez retrouver toutes ces informations sur cette page officielle de PHP.
Tout ça en attendant la sortie de la prochaine version 8.2, prévue initialement pour la semaine dernière, mais finalement reportée au 8 décembre [une dépêche est en cours de rédaction, NdA].
# Debian (trop) stable
Posté par Epy . Évalué à 6. Dernière modification le 28 novembre 2022 à 13:27.
Merci pour cette info, je ne suis pas d'assez près ce genre d'infos en général.
Question que nous sommes probablement plusieurs à nous poser:
Savez-vous ce qu'il va en être de Debian Bullseye qui a choisi PHP 7.4 dans ses dépôts stable; une mise à jour vers PHP8 semble peu probable en cours de route, ce n'est pas leur genre; va-t-il falloir se tourner vers les dépots backports pour les logiciels invitant très fortement à utiliser PHP 8 et supérieur ?
[^] # Re: Debian (trop) stable
Posté par Sébastien Koechlin . Évalué à 7.
Je ne veux pas me substituer à un expert Debian ou quelqu'un du projet. N'hésitez pas à compléter.
Normalement Debian Bullseye est parti avec PHP7.4 et ne passera pas à PHP8.
Si vous avez besoin de PHP8 parce qu'il y a des fonctions qui vous sont nécessaire ou que c'est pour un nouveau développement qui n'est pas pour demain matin, Debian Bookworm est pour l'instant sur la version 8.1. Ce n'est pas la version stable de Debian, mais elle s'installe sans trop de douleur; et pour développer, je n'ai jamais eu de soucis.
Pour Bullseye, normalement l'équipe en charge de la sécurité assurera dans la mesure du possible, le rétro-portage de tout correctif de sécurité détecté dans la 7.4 jusqu'à un an après la sortir de Bookworm. https://www.debian.org/security/faq#lifespan
C'est le cas au moins pour les principales distributions Linux qui assurent un suivi de sécurité de leurs paquets au delà du support "à la source".
[^] # Re: Debian (trop) stable
Posté par Epy . Évalué à 2. Dernière modification le 29 novembre 2022 à 11:17.
Dans mon cas c'était plus pour héberger des applis, telle Nextcloud, qui arrêtent le support assez rapidement, les nouvelles versions avec les mises à jour de sécurité ne seront pas disponible sur les anciens PHP.
Mais merci pour les informations complémentaires et aux commentaires en dessous :)
[^] # Re: Debian (trop) stable
Posté par Jérôme FIX (site web personnel) . Évalué à 8.
Tu as aussi la possibilité de passer par https://deb.sury.org/ pour installer les versions les plus à jour de PHP 7.4, 8.1 ou même déjà des versions de 8.2
Les instructions : https://packages.sury.org/php/README.txt
Jérôme
[^] # Re: Debian (trop) stable
Posté par zurvan . Évalué à 4.
C'est d'ailleurs ce qu'utilise Yunohost, car il est nécessaire d'avoir la version 8 de php pour certains paquets.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Debian (trop) stable
Posté par yosch . Évalué à 2.
et pour les utilisateurs d'Ubuntu, Ondřej Surý (développeur Debian qui s'occupe de PHP depuis un bon moment) cuisine les divers paquets de PHP et les sert sur ce PPA: https://launchpad.net/~ondrej/+archive/ubuntu/php
# PHP 5.x
Posté par Nic0 (site web personnel) . Évalué à 2.
En attendant y a toujours (beaucoup?) de vieux PHP qui tourne en production et qui ne veux pas mourir. Je serai curieux d'en avoir les statistiques si quelqu'un en a un lien. On est pas loin du zombie, PHP5.x, le mort-vivant.
[^] # Re: PHP 5.x
Posté par windu.2b . Évalué à 4.
Je suis actuellement développeur chez un journal national : on a encore du PHP 5.4 !
Je ne peux même pas écrire :
[^] # Re: PHP 5.x
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
(Analyse des logs Ruby on Rails de LinuxFr.org de début novembre 2022)
[^] # Re: PHP 5.x
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Pourtant, rendre le code compatible aux versions futures le rend plus maintenant et moins bogué, puis quand on migre on bénéficie de la vélocité des nouvelles versions mais on va préférer investir dans plus de hardware (CPU et RAM sans compter l'archi de l'infra qui devient overkill) pour à peine obtenir les mêmes résultats. Une fois que les managers avisés en auront marre, ils vont juste taper sur le langage (et dire que tel nouveau est mieux sans sourciller de l'énormité de comparer du PHP du siècle dernier avec la version actuelle d'un autre langage qui parfois n'est ps aussi performant que la dernière version de PHP.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: PHP 5.x
Posté par Micromy (site web personnel) . Évalué à 2.
Le problème est qu'une montée de version de langage a un coût non négligeable pour un résultat très peu visible la plupart du temps. Contrairement à un papier peint qui se décolle, un pneu qui crève ou une tâche indélébile sur une chemise, les programmes informatiques n'affichent pas beaucoup leur vieillissement, sauf le jour où ça plante et ça ne repart plus… (ou bien quand le nouveau jeune alternant fait un choc anaphylactique devant les écrans verts sur fond noir gérés avec les touches de fonctions).
[^] # Re: PHP 5.x
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
On est d'accord. Sauf que les DSI ont cru éviter un coût et ont fini par le déplacer ailleurs en plus de l'augmenter. Cerise sur le gâteau, on tourne sur un socle plus mis à jour depuis des lustres (7 ans en informatique ça fait beaucoup) mettant la sécurité en jeu (c'est du même accabit que de faire tourner Win95 ou de rouler avec des pneus usés) …sachant que ce sont des millions de chiffre d'affaire qui vont partir en fumée.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: PHP 5.x
Posté par barmic 🦦 . Évalué à 6.
Et que le défaut de sécurisation est puni par la loi de manière potentiellement vénère. C'est comme si les conducteurs de bus acceptaient de rouler avec des épaves. Ce n'est pas simplement leur confort qui est en jeu mais leurs utilisateurs et via le RGPD leur entreprise. Cela pourrait être apparenté à de la malfaçon.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: PHP 5.x
Posté par barmic 🦦 . Évalué à 5.
Non il est surestimé. Plus important encore quelque soit ce coût, il augmente avec le temps. Et non le manager n'a aucune idée de ce que c'est ni de son importance c'est aux gens techniques de le faire avancer tout comme c'est à eux d'expliquer ce que l'on peut ou ne peut pas implémenter.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: PHP 5.x
Posté par Christophe B. (site web personnel) . Évalué à 4.
C'est pas Dilbert qui disait que les incompétents on les mettaient à l'encadrement,
car c'est la qu'ils faisaient le moins de dégâts ?
[^] # Re: PHP 5.x
Posté par barmic 🦦 . Évalué à 2.
C'est pas à un manager d'avoir de la maitrise de ce genre de choses. C'est pas lui qui fait la veille technique pour savoir qu'elle est la santé technique du code.
Je suis pas très à l'aise avec ça. Ça porte des préjugés qui me paraissent dommageables (des préconçus sur le management, sur la manière d'envisager la compétence, sur comment on aime se placer sur du point de vu des développeurs,… et plus j'y réfléchis plus j'en vois).
Le principe de Peter est bien plus neutre à mon humble avis et s'applique quelque soit le métier. Et oui c'est un problème de considérer que le management est une suite logique d'un métier non-encadrant (sans chercher à cloisonner que quelqu'un se réoriente c'est très bien, mais comme toute réorientation ça se fait avec une formation).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: PHP 5.x
Posté par Christophe B. (site web personnel) . Évalué à 5.
Tout a fait d'accord mais il doit quand même connaître un minimum de choses, ou au moins être capable de comprendre
sinon autant confier une bibliothèque à quelqu'un qui ne sait pas lire
[^] # Re: PHP 5.x
Posté par barmic 🦦 . Évalué à 2.
Ou laisser l'écriture d'une symphonie à un sourd ? ;)
C'est un gradient moins il en sait plus il doit pouvoir déléguer/être à l'écoute des autres.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: PHP 5.x
Posté par Christophe B. (site web personnel) . Évalué à 5.
Pas mal comme réponse ;)
mais le cas est un peu exceptionnel quand même et AVANT d'être sourd il avait fait un peu de musique aussi :)
Avec le risque de déléguer n'importe quoi vers n'importe qui, ce qui devient une patate chaude que plus personne ne veut.
Sinon il délègue toujours les mêmes taches vers les mêmes personnes, ce qui cloisonnent complètement les choses, et certaines personnes se retrouvent nommé à vie pour certaines choses pénibles.
Ces managers la … tu peux les remplacer par une réunion d'équipe hebdomadaire et un outil style KANBAN
[^] # Re: PHP 5.x
Posté par barmic 🦦 . Évalué à 2.
C'était plus pour la blague qu'autre chose.
C'est là exactement le travail du manager. Organiser des gens pour qu'ils se parlent quand il y a besoin ou qu'il fasse la jonction si c'est plus pertinent et savoir quand et quoi déléguer à qui (et savoir que déléguer n'empêche pas d'accompagner).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: PHP 5.x
Posté par Christophe B. (site web personnel) . Évalué à 4.
Je connais le travail de "manager" ou d'encadrement, pour l'avoir pratiqué de temps en temps
sur des projets divers et variés, y compris en dehors de l'informatique.
Et cette expérience me permet de repérer "le bon grain de l'ivraie", et il y a du vécu aussi ;)
[^] # Re: PHP 5.x
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 02 décembre 2022 à 13:47.
Il y a des sourds qui y entendent des choses à la musique… (par contre faut qu'il y ait de la basse car c'est surtout le ressenti des vibrations… et sinon on peut apprécier aussi une partition à plusieurs niveaux)
Tiens, me rappelle un lien qui posait la question de savoir si les managers devaient être très compétents techniquement ou pas.
https://linuxfr.org/users/gilcot/liens/our-cto-should-actually-be-technical
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: PHP 5.x
Posté par Jérôme FIX (site web personnel) . Évalué à 5.
Cela ne fait que 7 ans qu'il n'y a plus de mise à jour de sécu (3 Sep 2015 )
https://www.php.net/eol.php
Vous êtes large !
[^] # Re: PHP 5.x
Posté par KiKouN . Évalué à 2.
Plus de maj de sécu officielles. Mais il y a des maj moins officielles pour php 5.6 et 7.X :
https://github.com/remicollet/php-src-security
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.