__o a écrit 218 commentaires

l'empreinte mémoire d'un processus php laissé en tâche de fond augmente.

Quand un processus réclame de la mémoire au système il ne la rend jamais; c'est le cas de tous les processus, pas seulement ceux de PHP.

Donc à la fin de la journée, la mémoire occupée par tes processus PHP c'est MAX(mémoire occupée par les scripts exécutés)

Apache aussi a un MaxRequestsPerChild.

Je parlais de tous ces exploits qui ont permis la désactivation de l'open_basedir, du safe_mode, du disable_functions

Non tu disais que php n'était pas réentrant; je pense que tu mélanges pas mal de choses

Je parlais de tous ces exploits qui ont permis la désactivation de l'open_basedir, du safe_mode

En même temps ce sont des features dépréciées, il est recommandé de ne pas les utiliser.

J'avais lu un article à ce sujet (dans misc peut-être)

C'était peut être un article sur l'exploitation d'une faille en particulier. La faille a certainement été corrigée avant même la publication de l'article. Je suis sûr que je peux trouver un article sur l'exploitation d'une faille dans python, ruby, et tous les moteurs js.

Je parle aussi du fait que l'utilisation sur des serveurs en thread n'est pas possible

PHP est thread safe quand il est compilé avec l'option qui va bien. D'ailleurs c'est la seule manière d'utiliser PHP en tant que module IIS sous windows. (Certaines bibliothèques peuvent ne pas l'être par contre; ou des trucs comme putenv/getenv; mais rien de spécifique à PHP ici.)

Par contre il n'y a aucun intéret à utiliser des threads plutôt que des processus séparrés.

L'utilisation en event n'est pas possible non plus car le processus php ne peut rester en tâche de fond pour cause de gonflement de l'empreinte mémoire

C'est ton script qui fuit.

sous apache ça te sert une page et pas en fastcgi

ou l'inverse non ? si le module php crash, apache aussi, donc connexion terminée; si un process fastcgi crash, apache va retourner une error 500.

Et permet moi d'avoir un léger doute quand je vois comment un serveur http a été introduit à l'arache dans la sapi cli

C'est pour le dev, pas pour la prod.

Pourquoi tu veux absolument utiliser tous les trucs dépréciés / non recommandés en prod ?

La gestion de la mémoire. php fuit,

La gestion de la mémoire n'a rien à se reprocher à mon avis. Et il n'y a pas de fuite de mémoire notable.

PHP utilise un allocateur spécial qui est réinitialisé après chaque requête (un peu comme Apache utilise un pool mémoire pour chaque requête). Donc même en cas de fuite mémoire, la mémoire serait récupérée à la fin de la requête.

php est capable de s'écraser lui même en parti, php n'est pas réentrant ...

Tu peux détailler ?

Le cas typique est une fonction qui boucle à l'infinie avec un final une page en module apache, pas de page en fastcgi.

Je pense que tu parle de récusion. En effet, PHP crash en cas de récursion trop profonde, parce que chaque niveau de récursion prend un peu de place sur la pile, et quand la pile est pleine, ça crash.

C'est pas spécique à PHP, si tu fais une "récursion infinie" en C tu obtiens exactement le même résultat.

D'ailleurs la seule façon d'obtenir un dépassement de pile depuis PHP 5.3 est de faire une récursion de fonctions natives, les fonctions utilisateur étant exécutées sans récursion, en interne.

une page en module apache, pas de page en fastcgi

Le fait est que dans un module apache, php est appelé par apache et donc la stack est déjà un peu remplie. Donc ça crash peut être une dizaine de récursions plus tôt, mais le comportement est le même en fastcgi.

La contrainte est qu'il faut assurer le recyclage des process, ce qui avec du code mal branlé et en haute charge peut se finir par un système qui passe son temps à forker. C'est aussi l'impossibilité d'utiliser php directement en threads ou en event.

De quoi tu parles ?

l'approche par sandboxing dans le core mais oui mais non (j'ai nommé le safe_mode, l'open_basedir

Ce sont des "features" dépréciée et désactivée par défaut dans 5.3.

Les fonctions magiques register_globals, magic_quotes

même chose

C'est dingue, les protocoles spécifiques au WiFi sont tous cassés.

Pourquoi les réseaux WiFi n'utilisent pas IPSec ou autres solutions de VPNs au lieu d'un truc spécifique au WiFi ?

En fait ça dépend de plusieurs trucs, mais d'après le code ce timeout est bien installé avant de lire les données POST, puis remplacé par max_execution_time avant d'exécuter le script.

Par contre ça peut dépendre du serveur http (qui peut buffuriser la requête), et de la plateforme (marche pas sous windows à priori).

La doc est ambiguë, mais max_input_time limite le temps de réception + parsage des données POST.

Les uploads de fichiers peuvent durer un certain temps, selon la taille du fichier et la bande passante. Je suppose que c'est pour ça.

En fait CRuby 1.8 est affecté par ce problème (corrigé il y a deux jours: [1]). Seule la version 1.9 ne l'était pas.

Pour PHP, un correctif a été pushé le 14 décembre (pas de release par contre).

Pour Tomcat la seule façon de contrer le problème est de limiter la taille des requêtes POST.

L'article [2] explique très bien le problème aussi.

Pour l’anecdote, on y vois que parmi PHP, ASP.NET, Tomcat, CRuby; PHP est celui qui résiste le mieux à l'attaque, et CRuby est celui qui résiste le moins bien (il consomme 100 fois plus de CPU que PHP pour la même attaque):

So you can keep about 10.000 Core i7 CPU cores busy processing PHP requests using a gigabit internet connection. Alternatively for ASP.NET, 30,000 Core2 CPU cores, or for Java Tomcat 100,000 Core i7 CPU cores, or for CRuby 1.8 1,000,000 Core i7 CPU cores, can be kept busy with a single gigabit connection.

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/391607
[2] https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos/

Quelle est la différence avec __thread qui était dans C99 ? http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Thread_002dLocal.html

Parce que visiblement elle ne fait pas l'unanimité. Et vu qu'elle n'a aucune importance pour l'association (pas une priorité), pourquoi pas ?

cette page n'est pas une priorité

J'ai bien compris, c'est pour ça que je proposais de supprimer cette page, et de juste faire une redirection à la place.

Voila qui montre à quel point cette association est ouverte aux suggestions.

Si tu veux remplacer le moteur de recherche derrière http://www.wikipedia.fr par une solution libre ; cela me semble tout à fait envisageable.

Pourquoi il y a un wikipedia.fr ET fr.wikipedia.org ? Quel est le but ?

Si c'est d'accueillir les utilisateurs qui tapent "wikipedia.fr" dans leur navigateur, pourquoi ne pas simplement faire une redirection vers fr.wikipedia.org ?

fr.wikipedia.org n'a pas de moteur de recherche ? Si non, alors ne vaudrait-il mieux pas contribuer, avec les autres chapitres, à l'amélioration de wikipedia.org au lieu de faire chacun votre site dans votre coin ? Si oui, alors à quoi ça sert ?

Je propose donc de juste faire une redirection de wikipedia.fr vers fr.wikipedia.org, ça prendra 2 minutes :)

Sur la question du moteur de recherche, on est vraiment dans le "yaka"

Il demandait aussi pourquoi ne pas simplement rediriger wikipedia.fr vers fr.wikipedia.org ?

According to Facebook, this PHP execution engine is 60 percent faster than its current PHP interpreter

Il est plus rapide que l'interpréteur actuellement utilisé par Facebook, qui est hphpi (pas l'interpréteur officiel).

Ils utilisent cet interpréteur pour développer, et utilisent le compileur en production.

D'après http://news.ycombinator.com/item?id=3349331 leur compileur static (HPHP donc) est toujours plus rapide que le JIT (the static compiler is beating our jit at most benchmarks at this writing).

OAuth2 est beaucoup plus simple.

OAuth utilise une connexion HTTP en clair, et donc doit implémenter des techniques pour vérifier l'authenticité des messages, chiffrage, anti-replay, nonce, etc. Le résultat est que consommer une API OAuth est assez complexe et requière une bibliothèque.

OAuth2 laisse ce travail à TLS, et du coup le protocole est hyper simple. Côté client une bibliothèque HTTP est amplement suffisante pour consommer une API OAuth2.

Forcer l'utilisation de TLS n'est pas un problème pour le client, à mon avis, tant que le serveur a un certificat de confiance.

OAuth2 est utilisé par Facebook entre autres, ce qui fait que la catégorie de développeurs qui a déjà touché à OAuth1 a certainement déjà touché à OAuth2 aussi.

Avec openid vs oauth, openid gagne :) http://www.googlefight.com/index.php?lang=en_US&word1=openid&word2=oauth

OAuth et OpenID ne servent pas à la même chose.

OpenID c'est pour t'identifier sur des sites externes en utilisant ton compte LinuxFR. L'avantage de OpenID c'est que ça marche sur tous les sites qui supportent OpenID, même si le site en question n'a jamais entendu parler de LinuxFR.

OAuth2 c'est plus pour consommer un service fournis par LinuxFR (l'API, dans ce cas): Un site spécialement conçu pour utiliser l'API de LinuxFR peut utiliser l'API en tant que toi, si tu lui en donne l'autorisation.

Les sites peuvent aussi s'en servir comme moyen d'identification, mais ce n'est pas l'usage premier de OAuth. Au contraire d'OpenID, il faut que le site gère l'identification via LinuxFR explicitement (comme ça se fait avec Twitter et Facebook, qui utilisent OAuth eux aussi).

Donc OAuth c'est bien quand on fournis une API, et OpenID c'est bien quand on veut fournir une identité.

Ha j'attendais que tu l'approuves, je vais pouvoir tester !!!!! (oui je m'exclame énormément)

Il y a beaucoup d'articles à propos de ces bureaux dans les résultats de google, et très peu de commerces. Le deuxième lien que tu donnes est le seul que j'ai trouvé. Pour le troisième, Ikea ne vend ce modèle qu'en Suisse.

Bonne idée :) Mais est-ce que ça se règle en hauteur aussi ? L'intérêt des bureaux debout est de pouvoir alterner les positions assis/debout.

Oui, et quand je paie (pas si cher que ça) j'ai moins l'impression d'être moi même le produit (c.f. https://twitter.com/#!/PartiPirate/status/89998194913718273 )

Spotify c'est gratuit, sans pub, et ils te forcent pas à avoir un compte facebook ?

Tu connais des alternatives ?

Parce que ça juste fonctionne dans mon navigateur (et pas Spotify)

Pour résumer:

• Le monsieur a trouvé une liste de serveurs dans le code source de TOR. (Et ça a dû être difficile parce qu'il lui a fallu un "algo maison" (sic) pour le trouver.)
• Il explique ensuite qu'il peut compromettre une partie du réseau en prenant la main sur les nœuds de cette partie du réseau; rien de bien étonnant
• Ensuite il explique qu'il a mis au point deux attaques, mais ce ne sont que des attaques par déni de service.

On débug très bien de l'assembleur dans gdb, alors pourquoi pas dans firebug ? Il faut juste que le programme embarque des informations de débug qui puisse faire correspondre un fichier sources et un numéro de ligne à une instruction. Biensûr certain pourront supprimer les informations de débug en prod pour que le programme reste léger en taille.

Et pour chainer des méthodes ? comme

$('body').find('.foo')
    .addClass('bar')
    .map(...)
    ....