Sortie de PHP 5.2.10

Posté par . Modéré par j.
Tags :
16
19
juin
2009
PHP
Une semaine après la sortie de la RC, les développeurs de PHP, langage de scripting open-source disponible sous licence PHP v3.01, annoncent la sortie de la version finale de PHP 5.2.10.

Cette version corrige plus de 100 bugs et améliore la stabilité de la branche 5.2.x de PHP. Tous les administrateurs de serveur PHP sont invités à mettre à jour leurs machines avec cette nouvelle version. Un peu plus de détail concernant les nouveautés de PHP 5.2.10:
  • Correction d'une faille de sécurité qui produisait des erreurs de segmentation avec exif_read_data() et certaines images jpg;
  • Ajout de l'option "ignore_errors" pour la fonction fopen (http);
  • Diverses optimisations et corrections relatives à la gestion de la mémoire: plus de corruption lors de la lecture des fichiers zip, correction des failles dans les fonctions ob_get_clean/ob_get_flush et imap_body;
  • Correction de l'erreur de segmentation provoquée par l'appel de session.save_path avec un chemin non valide;
  • Retour arrière concernant la valeur par défaut de l'option de tri de la fonction array_unique() à SORT_STING pour assurer la compatibilité descendante qui avait été introduite avec PHP 5.2.9;
  • L'opérateur @ fonctionne à présent avec les offsets;
  • Les entiers ne sont plus tronqués par la fonction json_decode();
  • La fonction ip2long a été corrigée pour ne plus retourner de valeurs erronées sur certain système 64bits.
  • # Bonne nouvelle, et du coup...

    Posté par (page perso) . Évalué à 2.

    ... faudrait en profiter pour prévenir quelques administrateurs dont, par exemple, ceux de free.

    Je vous laisse le soin de rallonger la liste.

    \_o<

    • [^] # Re: Bonne nouvelle, et du coup...

      Posté par (page perso) . Évalué à 3.

      Hem, la version PHP de Free est compilée par leurs soins, et dès qu'il y a une faille publiée, ils patchent eux-mêmes sans attendre une RC.... après, si ton but est d'avoi une version ultra-récente de PHP dans un serveur public qui diffuse des tonnes de sites différents, faut pas rêver... déjà qu'on a PHP4 ou 5 au choix...

      ⚓ À g'Auch TOUTE! http://agauch.fr

    • [^] # Re: Bonne nouvelle, et du coup...

      Posté par (page perso) . Évalué à 10.

      >... faudrait en profiter pour prévenir quelques administrateurs dont, par exemple, ceux de free

      php est la plate-forme web la plus merdique et la plus difficile à déployer. Tout simplement parce qu'elle nie complètement être une plate-forme, parce qu'elle souffre de choix de conception mauvais (genre url_fopen ou register_globals pour ne citer que les plus montrueux), parce qu'elle est une nébuleuse dans laquelle on trouve tout et n'importe quoi.

      Enfin parce que beaucoup de développeurs en php pensent que le monde est un vaste windows et php une plate forme normée et que donc si du code marche chez tel hébergeur, il doit forcement marcher partout et pour une durée infinie.

      Je pense que tu serais surpris de voir à quel point les admin en question connaissent le code de php et sont capable d'en comprendre les mécanismes, les problèmes et les évolutions. À quel point également php est souvent patché de façon importante, à quel point les choix des versions, et des libs associés demande du temps et de la validation.

      Un exemple con : fsockopen.
      fsockopen est une fonction toxique qui est souvent utilisée pour flooder. Il vaut mieux passer par l'implémentation directe des protocoles : imap, smtp, snmp ...
      Bref on peut raisonnablement dire que sur un serveur web, fsockopen n'a rien à faire. Le code d'un site web n'a pas en géneral à ouvrir directement des sockets. Et bien sans fsockopen, aucun webmail ne fonctionne.

      vi fsock.c
      host="localhost";
      C'est crade mais comment faire ? Filtrer les paquets sortants ?
      • [^] # Re: Bonne nouvelle, et du coup...

        Posté par (page perso) . Évalué à 6.

        En ce moment, il est toujours facile de cracher sur PHP.
        Surtout chez les utilisateurs Python ... Joris, regarde pas derrière toi, y'a un mur.

        Sinon, mise à part PHP, y'a un autre langage qui a permis de foutre dehors ASP chez pas mal d'hébergeurs ? ... attendez je réfléchis .... hmmm ... ah bah non, j'en trouve pas.

        En vous remerciant.
      • [^] # Re: Bonne nouvelle, et du coup...

        Posté par (page perso) . Évalué à 1.

        Je te rejoins sur ce point. Sans critiquer le langage PHP lui même, étant administrateur système je dois régulièrement déployer des serveurs faisant tourner PHP pour des utilisateurs qui n'y connaissent rien. Et bien on peut pas dire que les devs de PHP pensent beaucoup aux administrateurs. Si je devais faire mes doléances aux devs de PHP en temps qu'admin:

        - permettre de préciser un smtp et un port dans la configuration de PHP (seulement possible sous windows) serait un plus. Trop de developpeurs d'appli ne connaissent pas le module SMTP de pear.

        - permettre de positionner un niveau de sécurité plus flexible dans la configuration: local (aucun url_open), medium (autorisé vers certains domaine, ou que certaines fonction) et open (comme actuellement: tout ouvert à tous les vents)

        - pouvoir préciser un proxy http dans la configuration. Je sais qu'il est possible d'en préciser un via les contexts, mais cela est rarement prévu par les applications!

        - faciliter la mise en cluster de php: module de session en BD, prise en compte des cas avec reverseproxy qui permetterait de re-écrire les en-tête http en utilisant l'IP du client (contenue dans X-FORWARDED-FOR) plutot que celle du reverseproxy.
  • # Et sinon ?

    Posté par . Évalué à 6.

    Des nouvelles de PHP 6 ?

    Et surtout, se sont-ils décidés (pour PHP 6 ?) à profiter un peu plus de leur modèle objet et de l'usage des exceptions ?!?
    Parce que les fonctions qui t'envoient un message d'erreur dans la gueule, même quand ça n'est pas si grave (exemple : une authentification échouée sur un LDAP) on a connu mieux !
  • # PHP 5.3 c'est pour quand ?

    Posté par (page perso) . Évalué à 3.

    Pendant ce temps, PHP 5.3 se prépare. À ce que j'en ai lu, cette une petite révolution dans PHP (en attendant la grosse, PHP6 qui passe à Unicode, enfin !).
    http://www.nexen.net/actualites/php/17807-php_5.3_:_le_tour_(...)

    Je reste assez perplexe vis à vis de la syntaxe choisie pour les espaces de nom, et encore plus sur la nécessité de l'instruction goto. Pourquoi ne pas plutôt avoir introduit le try / finally (comme en Java, Delphi ou Python par exemple) ?
    http://www.php.net/manual/fr/language.namespaces.php
    http://www.php.net/goto

    Bon, il est vrai que l'utilisation d'une BD xkcd dans la documentation de GOTO le rend plus crédible.
    • [^] # Re: PHP 5.3 c'est pour quand ?

      Posté par . Évalué à 1.

      Je pense que cela est vraiment pour bientôt.

      La RC4 est sortie hier, et je ne pense pas qu'il y aura une RC5. D'ailleurs elle n'est sortie que quelques jours après la RC3, contrairement aux autres RC qui ont mis plusieurs semaines avant d'arriver.

      Donc, PHP 5.3, c'est vraiment pour très bientôt à mon avis :-)
    • [^] # Re: PHP 5.3 c'est pour quand ?

      Posté par (page perso) . Évalué à 5.

      J'ai commencé à pratiquer les espaces de nom avec PHP5.3 (paquets Dotdeb http://www.dotdeb.org/2009/06/16/php-5-3-0-rc3-packages-for-(...) et il faut avouer que c'est très pénible à utiliser.
      Au-delà de l'antislash comme séparateur d'espace, c'est surtout l'impossibilité d'importer le contenu d'un espace de nom dans un autre scope qui est pénible. Il faut aliaser un minimum.

      L'introduction de goto ne me choque pas : comment le Basic du Web a fait si longtemps pour s'en passer ? :D
  • # Also also featuring...

    Posté par . Évalué à 3.

    Il faut aussi noter que cette version corrige une grosse faille de sécurité concernant le safe_mode (vous savez, l'aberration qui fait croire aux hébergeurs qu'ils ne sont pas obligés de sécuriser leurs serveurs) sous systèmes Windows, qui était au moins présente sous toutes les versions depuis PHP 5.2.6.

    Mais bon, pour la plupart des hébergeurs, qui ont fait le bon choix de ne pas faire de l'hosting PHP sous Windows (je me demande d'ailleurs quel est l'intérêt, à part profiter de quelques extensions non portables), ça n'a aucune influence.

    Cf. http://bugs.php.net/bug.php?id=45997
    • [^] # Re: Also also featuring...

      Posté par (page perso) . Évalué à 10.

      >(vous savez, l'aberration qui fait croire aux hébergeurs qu'ils ne sont pas obligés de sécuriser leurs serveurs)

      Y en a un peu marre de ce fud perpétuel sur les hébergeurs qui n'ont pas déployés php comme dans "mon ubuntu"

      Le safe-mode est la seule tentative sérieuse de faire de php (l'interpréteur), un environnement d'exécution un tant soit peu adapté à son usage.

      La problématique des hébergeurs est de faire fonctionner du code globalement mauvais, et pour ainsi dire jamais mis à jour dans un environnement un tant soit peu sécurisé et avec des contraintes budgétaires fortes.

      La question n'est donc pas d'empêcher le code malicieux d'être injecté (puisqu'en l'occurrence l'hébergeur n'a pas la main sur ce point). La question est de limiter la casse. De faire en sorte que le code malicieux ne se transforme pas en spam, en vol massif de données ou pire en exploit.

      Bien utiliser le safe-mode permet de repérer les scripts uploadés via des failles et de restreindre sans l'interdire l'usage de la fonction exec. Il permet également de protèger la machine contre certains ini_set malheureux.

      Je doute que beaucoup d'hébergeurs fasse du safe_mode leur seul outil en terme de sécurité.

      Maintenant quand son site se fait pirater, c'est toujours plus simple de blâmer l'hébergeur qui en plus t'as honteusement coupé que de se dire que tu as écris/utilisé du code vulnérable.

      Si le safe_mode est désagréable, c'est qu'il est contraint par le fonctionnement interne de php. Soit j'interdis, soit j'autorise. Je ne peux pas restreindre et pour cause, je n'ai pas de serveur d'application (oups)


      Par ailleurs, quand tu vois les failles qu'il y a dans des choses aussi populaires que joomla, spip, phpbb ou drupal, quand tu vois que beaucoup d'agences vendent des sites sans maintenance, tu peux peux-être, en faisant un petit effort, comprendre qu'un hébergeur n'est sans doute pas le plus à blâmer.

      Je vais même te dire le fond de ma pensée. Moi j'aime bien mettre le safe_mode. Tu sais pourquoi ? Parce que je suis sûr qu'au moins quelqu'un aura une fois mis le nez dans le code déployé sur le serveur. Parce que le truc ne va pas marcher from scratch est qu'au moins une fois, quelqu'un aura jeté un oeil à la gueule du code.

      Moi je veux bien qu'on critique. Mais je prefererai qu'on m'éclaire sur la bonne façon de faire. Parce qu'en tout cas, c'est pas la doc de php qui va m'expliquer comment déployer son bordel.
      • [^] # Re: Also also featuring...

        Posté par . Évalué à 2.

        Le gros problème c'est que ça ne devrait à mon avis pas être le rôle d'un interpréteur de limiter ça. Iptables, les droits unix et des mises à jour de sécurité régulières résolvent respectivement les trois points que tu as cité dans ton 3ème paragraphe.

        Cependant, on trouve de plus en plus d'hébergeurs sur la toile (notamment tous ceux qui proposent des superbes offres gratuites sur leur kimsufi) qui préfèrent laisser reposer toute la sécurité de leur serveur sur le safe_mode de PHP (ou open_basedir, que je classe dans la même catégorie). Ces hébergeurs font tourner tous leurs sites webs sous un même utilisateur unix (www-data souvent, c'est le plus simple), et une fois qu'un moyen est trouvé pour outrepasser le safe_mode, c'est tous ceux qui ont fait confiance à l'hébergeur qui ont leurs données en danger. C'est très rare chez les hébergeurs pros car ils connaissent leur métier (et encore, on trouve des gens qui se lancent dans une société d'hébergement sans aucune connaissance, mais ça n'aboutit que rarement), mais il me semble bien que c'est arrivé à quelques hébergeurs du RHIEN (http://www.rhien.org/) il y a quelques temps, par exemple.

        Après, ça n'est que mon avis d'étudiant ne faisait pas de web de manière professionnelle et qui préférerait éviter PHP pour cette tâche (et ne justifierai pas de ce choix ici avant vendredi prochain), et je ne t'oblige pas à le partager.
        • [^] # Re: Also also featuring...

          Posté par . Évalué à 4.

          (et ne justifierai pas de ce choix ici avant vendredi prochain)

          La dépêche ayant été publiée un vendredi, tous les trolls relatifs, même postés plus tard, sont rétroactivement tolérés, non ? ;-)

          De toute façon le safe_mode est activé, tu ne risques rien (et nous non plus) :D
        • [^] # Re: Also also featuring...

          Posté par (page perso) . Évalué à 4.

          >Ces hébergeurs font tourner tous leurs sites webs sous un même utilisateur unix (www-data souvent, c'est le plus simple),

          Tu perd alors tous le bénéfice du safe-mode. Qui est justement de pouvoir distinguer un script légitime d'un script uploadé malicieusement.

          >Le gros problème c'est que ça ne devrait à mon avis pas être le rôle d'un interpréteur de limiter ça.

          Tout à fait c'est le rôle d'un serveur d'application.

          >Iptables, les droits unix et des mises à jour de sécurité régulières

          Non. Si quelqu'un uploade un mass mailer (ce qui est le cas le plus courent), ni iptable, ni les mises à jour du serveur et des logiciels, ni les droits unix ne pourront te permettre de prévenir l'envoie de spam.
        • [^] # Re: Also also featuring...

          Posté par . Évalué à 2.

          Iptables, les droits unix et des mises à jour de sécurité régulières résolvent respectivement les trois points que tu as cité dans ton 3ème paragraphe.

          Un utilisateur unix séparé par client de l'hébergeur, ça veut dire un (ou plus) processus dédié par utilisateur au niveau du serveur Web. S'il y en a plusieurs centaines, cela commence à être gênant, non ?
      • [^] # Re: Also also featuring...

        Posté par (page perso) . Évalué à 1.

        le safe_mode est un cauchemar pour les développeurs PHP, surtout dés que tu manipule des fichiers dynamiquement. genre, tu arrive à creer un fichier, et la requete d'après, tu ne peux plus y toucher, à cause de ces droits mal foutus.

        Et puis ça apporte plein d'autres problèmes que je n'ai plus en tête, à tels point que de l'aveu même des core-developer de PHP, safe_mode c'est du vent, c'est de la fausse sécurité et ça sera supprimé dans PHP6.
        • [^] # Re: Also also featuring...

          Posté par . Évalué à 3.

          Je citerai d'ailleurs le manuel PHP (http://fr2.php.net/features.safe-mode ) :

          The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.
          • [^] # Re: Also also featuring...

            Posté par (page perso) . Évalué à 2.



            The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.



            Le manuel de php en ce qui concerne la partie administration est une vaste blague.

            php a été conçu pour faire fonctionner du code web directement. Sans l'intermédiaire d'une architecture n-tiers compliquée.

            Le principe est simple le serveur web -> l'interpréteur -> le code. On ne passe même pas par une lib (comme en perl use CGI)...

            Ce principe implique que l'interpréteur sert directement l'application. Donc si on ne met pas de sécurité dans l'interpréteur ? On la met où ?

            La philosophie unix veux que l'on sépare les choses très distinctement. L'état de l'art (les DESIGN PATTERN et tou l'toutim) expliquent à peu près la même chose.

            php prends le partie inverse. Ce n'est bien sûr pas obligatoire de l'utiliser comme ça. Mais c'est possible et même encouragé ( ne serais-ce qu'en mélangeant le html et le php dans le même fichier).


            PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.

            Donc de deux choses l'une soit php nécessite une séparation claire de la logique applicative (écrire des fichiers, envoyer des mails ...), soit php fournie les moyens de sécuriser son interpréteur.

            quelqu'un qui ecrit :
            <? mail($_POST[to],$_POST[subject],$_POST[message],$_POST[headers]);
            ?>

            Dans un fichier et le laisse accessible depuis le web. Tu fait comment avec tes droits unix, ta mta et tes mises à jour de sécurité pour empêcher un spammeur de l'utiliser.

            Tu fait le goret... tu lis/filtre les mails sortants, tu compte les mails ...

            C'est pas un problème en l'air. C'est un exemple pratique et bien concret auquel le manuel php ne donne aucune réponse. Celui de java le fait, celui de RoR également.

            > It is architecturally incorrect
            php is architecturally incorrect c'est d'ailleurs pour ça qu'il est si facile à utiliser.
            • [^] # Re: Also also featuring...

              Posté par . Évalué à 4.

              C'est pas un problème en l'air. C'est un exemple pratique et bien concret auquel le manuel php ne donne aucune réponse. Celui de java le fait, celui de RoR également.

              Ah, et c'est quoi la réponse de java et RoR au problème que tu évoques plus haut, à savoir une méthode qui ferait l'équivalent moral de :

              <? mail($_POST[to],$_POST[subject],$_POST[message],$_POST[headers]);
              ?>

              Soit l'envoi de mail est interdit et aucune web-app ne peut envoyer de mail, soit l'envoi de mail est autorisé et passer d'un langage à un autre ne protège pas contre le code pourri du genre de ci-dessus. Ton argumentaire ressemble beaucoup à du brassement d'air.
      • [^] # Re: Also also featuring...

        Posté par (page perso) . Évalué à 3.

        Le safe-mode est la seule tentative sérieuse de faire de php (l'interpréteur), un environnement d'exécution un tant soit peu adapté à son usage.

        La seule ? Suhosin et suPHP c'est du vent ?
        http://www.hardened-php.net/suhosin/a_feature_list.html
        http://www.suphp.org/
        • [^] # Re: Also also featuring...

          Posté par (page perso) . Évalué à 1.

          >La seule ? Suhosin et suPHP c'est du vent ?

          Suhosin n'est pas php et c'est pas du vent loin de là.

          suPHP à cause de la gateway cgi aux performances désastreuses n'est souvant pas utilisable. Ce n'est pas php non plus.

          J'aurais du dire 'la seule emmenant directement de php".
          • [^] # Re: Also also featuring...

            Posté par (page perso) . Évalué à 3.

            apt-get install apache2-mpm-itk

            <VirtualHost *>
            AssignUserID bohwaz bohwaz
            ServerName bohwaz.net
            DocumentRoot /home/bohwaz/www
            </VirtualHost>

            Et voilà. Ah et ça marche avec PHP en module, donc même perfs qu'un apache normal.

            « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

            • [^] # Re: Also also featuring...

              Posté par (page perso) . Évalué à 1.

              >Et voilà. Ah et ça marche avec PHP en module, donc même perfs qu'un apache normal.

              Je ne connaissais pas ce worker. On gagne beaucoup par rapport à suexc / fastcgi mpm-worker ?
              • [^] # Re: Also also featuring...

                Posté par (page perso) . Évalué à 2.

                En perfs ? C'est équivalent à apache normal avec php en module, j'ai jamais essayé fastcgi, mais suexec c'est chiant à configurer, alors que là suffit d'apt-get install et d'assigner un uid/gid à chaque vhost.

                « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.