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.
Aller plus loin
- Annonce de la sortie de PHP 5.2.10 (8 clics)
- ChangeLog (4 clics)
- PHP sur dmoz (7 clics)
# Bonne nouvelle, et du coup...
Posté par finss (site web personnel) . Évalué à 2.
Je vous laisse le soin de rallonger la liste.
\_o<
[^] # Re: Bonne nouvelle, et du coup...
Posté par ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Bonne nouvelle, et du coup...
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
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 Prae . Évalué à 6.
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 ArnY (site web personnel) . Évalué à 1.
- 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 windu.2b . Évalué à 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 Victor STINNER (site web personnel) . Évalué à 3.
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 ethtezahl . Évalué à 1.
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 LupusMic (site web personnel, Mastodon) . Évalué à 5.
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
[^] # Re: PHP 5.3 c'est pour quand ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je viens de voir les espaces de noms, c'est vrai que vu comme cela, ce n'est pas compréhensible comme choix. Normalement, l'antislash est réservé pour coder ou protéger des caractères dans la tradition des langages utilisant la mouvance du C.
[^] # Re: PHP 5.3 c'est pour quand ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Le choix de l'anti-slash vient d'une limitation du moteur de scripting. L'usage de l'opérateur de résolution de portée ne permettait pas de résoudre les classes, les fonctions et les espaces de nom du même niveau. Du coup, un sondage a été effectué pour déterminer quel serait l'opérateur de résolution de portée des namespaces.
D'ailleurs, l'antislash poses problème lorsqu'on veut écrire des callbacks. Beaucoup de débutants ne vont pas comprendre pourquoi "project\tables" « ça marche pas » :D
[^] # Re: PHP 5.3 c'est pour quand ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
On trouve cette série sur le site
https://www.techworld.com.au/tag/a-z%20of%20programming%20la(...)
La page concernant Larry (avec 2 r) Wall et Perl est
https://www.techworld.com.au/article/270267/-z_programming_l(...)
Le court passage sur PHP est en haut de la page 5
https://www.techworld.com.au/article/270267/-z_programming_l(...)
# Also also featuring...
Posté par Pierre Bourdon . Évalué à 3.
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 Joris Dedieu (site web personnel) . Évalué à 10.
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 Pierre Bourdon . Évalué à 2.
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 santos . Évalué à 4.
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 Joris Dedieu (site web personnel) . Évalué à 4.
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 Antoine . Évalué à 2.
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 Kangs . Évalué à 2.
[^] # Re: Also also featuring...
Posté par DitOuQueMon . Évalué à 2.
[^] # Re: Also also featuring...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
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 Pierre Bourdon . Évalué à 3.
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 Joris Dedieu (site web personnel) . É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 Antoine . Évalué à 4.
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 Nicolas (site web personnel) . Évalué à 0.
[^] # Re: Also also featuring...
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
security manager
>et RoR
Le modèle MVC
Même perl propose quelque chose (-T)
>ne peut envoyer de mail
Le problème n'est pas d'envoyer un mail mais de sécuriser ses variables.
[^] # Re: Also also featuring...
Posté par Victor STINNER (site web personnel) . Évalué à 3.
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 Joris Dedieu (site web personnel) . Évalué à 1.
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 BohwaZ (site web personnel, Mastodon) . Évalué à 3.
<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 Joris Dedieu (site web personnel) . Évalué à 1.
Je ne connaissais pas ce worker. On gagne beaucoup par rapport à suexc / fastcgi mpm-worker ?
[^] # Re: Also also featuring...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
« 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.