> Cette liste est à prendre pour ce qu'elle est (donc rien de sérieux)
> mais illustre tout de même les "tendances" du web.
Ben non puisque tu dis toi même qu'il y a eu une google bomb d'organisée pour associer w3c et http. Enfin tu ne le dis pas mais je le confirme puisque j'ai vu pas mal de blog le faire.
Reste après que les navigateurs et langages de programmation sont potentiellement sur-représentés puisqu'ils traitent potentiellement justement de HTTP ou du moins de protocoles et programmation réseau (Google tient compte des regroupements de ce type).
On peut même imaginer que la petite bombe (pas bien grosse, il est vrai), associée à une actu HTTP quelconque au même moment sur des sites libres, ait pu faire créer à Google un groupe de site orienté "logiciel libre et programmation".
Bref, aucune chance d'y récupérer même des tendances ou des conclusions comme les tiennes.
C'est quand même phénoménal qu'on mette en équivalence 30 messages courts dont la qualité de service n'est pas assurée et qui servent majoritairement de bouche trou sur les réseaux (ils peuvent être transmis en 5 minutes comme en 12 heures) et de l'autre coté 5h de communication.
Même si on se limite aux portables, on met en comparaison 30 messages courts avec 20 minutes de conversation, alors qu'un message court ne doit pas prendre plus de 5s (à tout casser) pour l'envoi/reception et qu'il n'a aucune assurance de qualité de service.
C'est encore plus monstrueux quand je vois qu'on peut téléphoner 3 fois plus longtemps au Brésil que sur un portable. Quelqu'un m'explique ?
Rahh, mais j'en ai marre.
Ici dès qu'on conteste un point d'argumentation on a l'impression de passer pour le grand méchant de service qui rejette tout le fond en bloc.
Mis à part ta première phrase (*) je ne vois pas à quoi répond tout le reste.
Pour faire clair : oui je suis furieusement contre ce projet de loi qui me semble très mauvais et dangereux. Voilà, c'est clair comme ça ?
* (effectivement une loi qui cherche à interprété les intentions est dangereuse on est d'accord, mais à ce moment là c'est ça qu'il faut critiquer, et pas dire que la loi interdit tout alors que c'est faux ; c'est uniquement ça que je reproche)
> Je parlais des machines servant au coeur de métier d'une entreprise, des
> machines ayant besoin de logiciels au dessus qui n'existent pas en libre, de
> logiciels qui interesseraient au maximum 100 entreprises dans le monde
Donc on a le choix de parler standardisation pour :
- 100 entreprises dans le monde
- les PME
- les particuliers
S'il y a bien un domaine qui me parait hors propos c'st celui de ta superbe entreprise avec des contraintes et des logiciels qui ne concernent que 100 entreprises dans le monde.
Eux ont largement les moyens d'adapter une fois leur logiciel pour qu'il passe sur leur nombreuses installations, ou de faire de la personalisation sur la machine s'il n'y en a qu'une, ou même de demander une adaptation à l'éditeur.
Je ne sais pas si ta superbe entreprise avec tes contraintes pas possible est réelle ou pas mais peu importe. Pour le coup on ne normalise pas toutes les distribs rien que pour les 100 boites concernées. Non, la normalisation l'intérêt c'est justement pour les autres, la masse, ceux qui n'ont pas les moyens de faire autrement.
> Bref, faudrait peut-etre aller voir autre chose que des PME, tu verras que les
> besoins ne sont pas les meme, qu'il y a plein de contrainte ssur les installations
> (une seule distribution autorisée si et seulement si elle est configurée de telle
> manière par exemple), qui font que tu ne peux pas faire ce que tu veux, et c'est
> la que la LSB sert.
Ah ? s'il n'y a qu'une seule distrib, sur laquelle on n'installe que des choses certifiées, on s'en fout un peu de savoir si elle est LSB ou pas hein.
La LSB elle sert justement pour compatibilité quand tu veux supporter plusieurs distrib. Enfin je dis ça, j'ai peut être mal compris un truc mais bon ...
C'est marrant mais ton post me donne largement envie de penser le contraire de toi à propos de QT
> il suffit de prendre des précautions sur le phrasé pour que toutes
> informations sur le sujet ne semble "pas destinée à alterer le
> fonctionnement d'une mesure de protection."
Là je vais accepter de me faire traiter de naif, mais je pense les juges suffisament intelligents pour faire la différence entre quelqu'un qui publie un avis de sécurité et quelqu'un qui met une suite de crack sur sa page avec un "disclaimer: le contenu de ce site est là pour éducation et pas pour être utilisé".
Toujours est-il que les articles dont on parle ne sont pas des exceptions à une règle générale, c'est donc au plaignant d'apporter suffisament d'éléments à charge pour convaincre le juge que tu ton but était bel et bien la mise en défaite des systèmes de protections.
> Ou est la limite ? N'est-ce pas évident que l'information d'une
> faiblesse peut servir pour l'exploiter ?
Globalement similaire à un "le coup est parti tout seul" et un "je l'ai visé", à la diffamation (qui parle d'intention de nuire), et à pleins de trucs dans la loi qui parlent d'intention, de volonté ou de "consciement". C'est au juge de trancher de bonne foi.
Parfois c'est effectivement limite, il peut effectivement y avoir des ereurs, mais je ne pense pas qu'il soit bon de confondre le "destiné à" et le "permet de", ou de laisser entendre que c'est la même chose.
Si on ne fait pas nous même la distinction ce sont les gens à qui on s'adresse qui vont la faire et nous retourner un "on continue avec ce projet de loi, visiblement vous n'avez pas compris"
Je me permet de changer l'emphase parce que tu as AMHA sauté le terme intéressant :
fournir un service ou une information destinés à faciliter ou à permettre [...]
et de rappeler à quoi je répond :
Si personne n'est autorisé à travailler ou communiquer sur la sécurité des systèmes, ca limite les corrections de failles de sécurité.
Tu peux travailler sur la sécurité, communiquer sur ce que tu fais si ta communication n'est pas destinée à alterer le fonctionnement d'une mesure de protection.
Ta communication ou ton travail peuvent être destinés (entre autres) à :
- informer sur la faible sécurité de ces systèmes
- améliorer la sécurité de ces systèmes
- détailler la sécurité dans un but de formation
- corriger les problèmes de sécurité ou fonctionnement de ces systèmes
Bref, le projet de loi vise l'intention et le but, pas l'effet et les possibilités. Ca ne t'empêche nullement de travailler ou communiquer sur la sécurité de ces systèmes, ni de publier des corrections.
Oui c'est une "information" (ton emphase), mais non, elle n'est pas destinée à contourner les mesures de protection (mon emphase), donc elle n'est pas visée par le 3° que tu cites.
La seule chose que ça t'interdit c'est de dire "bon, je vais vous aider à casser les systèmes parce que j'ai vu une faille de sécurité, voilà comment il faut faire ...".
Je trouve totalement crétin et mauvais de pénaliser le contournement d'une protection et pas le délit réel que la protection souhaite empêcher, ça ouvre trop de dérapages possibles et trop de cas couverts alors qu'ils ne le devraient pas.
Par contre non, ça ne t'empêche pas de faire de la recherche en sécurité, de faire du logiciel libre ou d'étudier/commenter ces dispositifs. Du moins pas d'après ma lecture.
> Faut pas rêver, même si objectivement c'est pas "oui", en pratique ça
> deviendra "oui" parceque leurs avocats seront plus forts, plus
> nombreux, plus tout.
Pour faire des pressions ou des procès à gogo sans fondement légal et uniquement grace à la pression judiciaire et des avocats, ils n'ont pas besoin de loi (puisque sans fondement légal)
La loi elle même ne te retreint pas la dessus. Certes d'aucun peuvent faire peur avec , mais ils n'ont pas attendu ce projet pour faire peur. Il y a plein de lois qu'on peut faire semblant de mal interpréter.
Bref, on est en train de reprocher à la loi d'interdire des choses qu'elle n'interdit pas. Ca ne me parait pas cohérent (il y a suffisament de choses qu'elle interdit et qui sont mauvaises pour ne pas en inventer) ni intelligent (je vois bien les réponses "vous n'avez pas compris" qu'ils feront, et avec raison puisqu'on argumente de travers)
> Cette loi est une saloperie qui nous empêchera, au regard de la loi,
> de faire à peu près tout ce qu'on fait actuellement avec nos ordis...
Je ne sais pas ce que tu fais avec ton ordi, je suis d'accord avec toi que ce projet de loi est une saloperie, mais une grosse partie (de ce dont on parle ici) n'est justement pas empêchée "au regard de la loi". C'est justement le fond de mon intervention.
Je ne lis pas la même chose. Où vois tu qu'il faut demander l'autorisation ? moi je lis dans l'arrêté qu'il faut faire une déclaration préalable, ce qui n'a un peu rien à voir : la déclaration n'implique pas de réponse ou refus/acceptation par le destinataire.
Le décrêt parle bien d'une autorisation mais de ce que j'en comprend (la flemme de suivre les n° de loi) ça doit se référer à d'autres réglementations tout à fait indépendantes : plan de vol, zones habituellement interdites au survol (militaires, aglomérations, ...), hauteur au sol du vol. bref, des choses qui sont déjà réglementées (pour des bonnes raisons). Je n'y vois pas d'autorisation de prise de vue.
Je peux faire une erreur (vu que j'ai pas fait l'effort d'aller lire la loi de départ qui a été modifiée ni les références données des articJe ne lis pas la même chose. Où vois tu qu'il faut demander l'autorisation ? moi je lis dans l'arrêté qu'il faut faire une déclaration préalable, ce qui n'a un peu rien à voir : la déclaration n'implique pas de réponse ou refus/acceptation par le destinataire.
Le décrêt parle bien d'une autorisation mais de ce que j'en comprend (la flemme de suivre les n° de loi) ça doit se référer à d'autres réglementations tout à fait indépendantes : plan de vol, zones habituellement interdites au survol (militaires, aglomérations, ...), hauteur au sol du vol. bref, des choses qui sont déjà réglementées (pour des bonnes raisons). Je n'y vois pas d'autorisation de prise de vue.
Je peux faire une erreur (vu que j'ai pas fait l'effort d'aller lire la loi de départ qui a été modifiée ni les références données des articles de loi connexes), mais ce qui me parait grave moi ça serait surtout de faire dire de telles choses à une loi qui ne les dit pas du tout, et de s'en servir dans une argumentation.les de loi
dans "afin d'altérer la protection" et "destinés à faciliter ou à permettre la réalisation", les mots clés ce sont "afin" et "destinés".
Peut importe que ça altère. La question c'est plus : est-ce que c'était le but ? Ce projet de loi ne concerne que les cas où tu dis "oui".
Ca ne t'empêche pas d'en parler, de l'étudier, ou même de détailler ce mécanisme et ces faiblesses. Enfin uniquement si *ton but est* de les contourner et d'en altérer le fonctionnement.
Où voyez vous cette interdiction de travailler ou communiquer sur la sécurité des systèmes ?
Je serai tenté de dire *FUD*
Ce qui est interdit c'est de faire une comm ou une action, en vue d'altérer la protection.
On parle du but de l'action, du logiciel ou de la communication, pas de ce qu'il peut faire. Si ta recherche ou ta comm a pour but d'informer des limitations de ces protections, de leurs effets, d'éduquer ou de former sur leur fonctionnement, d'en corriger la sécurité ou améliorer le fonctionnement .... il n'y a rien (que j'ai vu) qui t'en interdit.
(attention, ça ne veut pas dire que ce projet est bon, mais si on veut être crédibles pour bloquer ce qui pose problème il faut évityer de faire du *FUD* et parler de problèmes imaginaires, il y en a assez de réels comme ça).
Militer pour ne pas avoir du tout de projet de loi et tout rejeter en bloc ne fonctionnera probablement pas. Ils sont fondés à faire un projet de loi sur ce sujet et ils en ont même l'obligatoire (transposition de l'EUCD).
Par contre, ce qui me parait plus constructif de proposer des améliorations pour que ce projet ne fasse pas tout le mal qu'on y voit. Ca me parait aussi beaucoup plus réaliste à obtenir :
- faire rejeter les articles qui négatifs qui ont été ajoutés depuis l'EUCD
- ajouter des exceptions ou renforcer les existantes pour ne pas totalement déséquilibrer les droits d'auteurs
- ajouter des mécanismes pour protéger l'utilisateur d'un monopole ou d'un contrôle de ses propres systèmes par les mesures de protection (en gros mettre dans la loi un truc contre "l'informatique de confiance") ou ajouter une limitation ne protégeant que les protections qui ne créent pas une dépendance ou un subbordination des utilisateurs aux producteurs
- ajouter une exception pour permettre l'intéropérabilité (plus explicite et forte que celle qui est présente dans ce projet de loi)
- ajouter une exception pour permettre la relecture d'oeuvres acquises de manière licite
- ajouter un mécanisme pour empecher que les mesures de protection des droits d'auteurs deviennent des manières de verrouiller les droits des utilisateurs et concurrents (cf l'affaire des cartouches lexmark)
- dépénaliser tout contournement qui n'a pas pour effet ou pour but la violation des droits d'auteurs (la protection des droits d'auteurs est le seul but de cette loi, donc ça ne devrait pas couvrir autre chose)
etc.
Ca me parait pouvoir avoir un effet bien plus grand et efficace que le simple rejet en bloc.
Oui, il y aura un sous type, qui dicte s'il s'agit d'une chaîne binaire ou d'une chaîne unicode. Ca va d'ailleurs demander un peu de boulot sur toutes les fonctions et extensions pour gérer cette dualité (le cas par défaut étant "chaine binaire opaque", donc au pire on n'a pas le support unicode et on reste comme actuellement)
> En quoi est ce génant que php incorpore directement ce type de code
Parce que ça veut dire rajouter dans PHP un code qui n'a rien à voir avec le langage de programmation, qui est très sensible coté sécurité, et qui de plus risque de ne pas être portable aussi bien que PHP (il faut au minimum un ifdef pour windows)
Avoir plusieurs softs, chacun avec un role et une fonction définie c'est bien. Les gros trucs monolithyques qui font le café c'est inmaintenable assez vite.
> Suexec ne permet absolument pas de remplir ce rôle.
> Et s'il en existe d'autres, il n'en existe pas tant que ça non plus.
Il le tient pourtant à plein d'endroits. Ca doit être le wrapper le plus utilisé pour ça. Pourquoi ne pourrait-il pas convenir d'après toi ?
Et s'il n'en existe pas des centaines d'autres il doit bien en exister 3 ou 4 de courants, ce qui est largement assez pour un soft de ce type.
> De permettre d'avoir un système sécurisé sans devoir rajouter quoi
> que ce soit d'autre.
Tu rajoutes bien apache, tu rajoutes l'OS, tu rajoutes les libs, tu rajoutes tes comptes utilisateur ... PHP ne contient pas tout et n'est pas fait pour ça. Pourquoi vouloir intégrer suexec et pas directement le serveur Web par exemple ?
C'est un langage de programmation, pas un serveur d'application, et encore moins une plate-forme complète.
C'est vrai que la syntaxe ereg est moins cryptique ([troll] faut dire que preg ça vient du monde perl [/troll])
Les fonctions mysql_* vont peut être disparaitre. Maintenant :
- tu auras des mysqli_* qui fonctionneront quasiment pareil, il suffit de faire un rechercher/remplacer et corriger un ou deux détails (la phase connexion entre autres)
- rien ne t'empêche de compiler toi même l'extension mysql sur ta version de PHP, ou d'utiliser une bibliothèque qui reprend les fonctions mysql pour les diriger vers mysqli
Bref, c'est plus clean pour PHP mais ça ne te retire pas grand chose. De toutes façons d'ici que ce PHP6 sorte il est peu probable que tu utilises encore du mysql 3.23 donc de toutes façons les fonctions mysql_* actuelles n'auraient pas fonctionné.
> vu que sur une de mes machines j'ai un mysql 4.0.17 qui tourne et que je continue
> a utilise les fameuses fonction mysql_* je me dis que vos post en sont pas sur la
> même longueur d'onde
Oui, en fait je prend un raccourci. La cassure n'est pas sur 3.23 / 4.0 mais sur 4.0.x / 4.0.y, je ne me souviens plus exactement où.
Il y a aussi des gens qui utilisent les mysql_* avec mysql 4.1 et > mais c'est au prix d'une bidouille (une config spéciale du serveur mysql qui lui demande d'utiliser les anciens protocoles d'authentification)
> vu que le changement n'est applicable que pour le temps ou le fichier est traité,
> j'etais (je le suis encore) convaincu qu'on pouvait utiliser ini_set() pour mettre
> les register global a off, ainsi que les magic_quotes.
Non, parce que quand il lit ton fichier, il a déjà initialisé (ou pas) les globales, et a déjà opéré (ou pas) l'échappement des magic_quotes_gpc.
> moi, perso... la suppression de mysql, c'est putot une decission politique non ?
> (licence GPL)... faut-il s'en rejuire ?
C'est effectivement à l'origine une décision politique, mais pas du groupe PHP. Ca vient du groupe Mysql.
En gros l'ancien client Mysql était typé LGPL ou BSD (je ne sais plus) pour qu'une appli non compatible GPL puisse se connecter à un serveur Mysql.
Ils ont voulu restreindre un peu plus et le nouveau client à partir de mysql 4.0 (celui qui permet de se connecter à mysql 4.1) est GPL uniquement. Pour que les gens ne continuent pas à utiliser l'ancien client ils ont changé le système d'authentification (ou plus précisément le cryptage des mots de passe). On créé l'incompatibilité pour forcer la mise à jour, donc la nouvelle licence, donc le paiement de la licence proprio pour ceux chez qui ça ne convient pas.
Le premier défaut c'est qu'on se retrouve avec deux clients mysql différents. Ca explique qu'on ait maintenant deux extensions "mysql" et "mysqli". Le second défaut c'était que l'extension "mysql" était fournie par défaut avant. On ne peut pas faire la même chose avec "mysqli" parce que si PHP est du logiciel libre (assez proche de BSD), ce n'est pas du logiciel compatible GPL. (note; ce problème de licence a été réglé depuis)
Donc oui, c'est bourré de politique là dedans. Mais bon, c'est comme ça.
> mysqli aurat'il des perfs comparable ?
oui
> faudrat'il se payer le code des appli php pour changer les appels de mysql ?
Non si tu contrôles ton serveur, tu peux le bidouiller pour te connecter avec l'ancien client (utiliser l'ancien cryptage des mots de passe)
Oui sinon, mais les modifs à faire sont assez simples.
Maintenant on parle de PHP6, qui au mieux sortira en décembre 2006 (au mieux). Aujourd'hui, un an et demi après PHP 5.0, 95% des gens sont encore en PHP4.
Autant dire que rien ne t'obligera à être en PHP6 à ce moment là, donc à changer quoi que ce soit à ton code.
Le problème de ça c'est que tu *sais* que ton code n'est pas portable.
Certes, strlen() fonctionnera sur les chaînes UTF8
Mais ceux qui utilisaient strlen() pour calculer le nombre d'octets (ils sont nombreux vu qu'il n'y avait que ça pour le faire) auront des problèmes. Si tout le code PHP qui tourne n'est pas le tien tu risques des ennuis.
Pire, ça essayera de jouer avec l'UTF8 dans tes champs binaires, types les fichiers compressés. C'est dommage et ça peut casser certaines choses (impossible de retirer les X derniers octets d'un flux binaire opaque).
A partir du moment où tu ne codes que pour mbstring, c'était mieux de le faire explicitement. Tu ne pourris pas tout ce qui cherche à calculer des nombre d'octets, et ça fonctionnera chez ceux qui ont mbstring sans avoir activé l'overload.
De toutes façons chez ceux qui n'ont pas mbstring l'appli aurait buggué donc autant que ça plante en ralant sur mbstring, c'est même presque mieux.
L'overload mbstring c'est à restreindre à des cas très précis. Par exemple l'internationalisation "en catastrophe" d'une appli qui n'était pas prévue pour.
> est-ce la même syntaxe ?
> si non : pas uen bonen idée de supprimer car ca casse tout.
> si oui, il suffit de faire un wrap entre les 2 fonctions.
> conclusion : pas la peien de supprimer .
Non, ce n'est pas la même syntaxe.
Ceci dit si tu ne sais pas ça (c'est à dire que tu n'as aucune connaissance sur le sujet), et dit vraiment sans aucune agressivité ni aucun reproche, je ne suis pas sûr qu'exprimer un avis avant de te documenter soit forcément pertinent.
Pour le wrapp c'est justement ce qui a été proposé un temps (cf le commentaire auquel tu répond). Reste à voir si ça vaut le coup, si beaucoup de gens ont du ereg() difficile à passer en preg().
De toutes façons les gens qui auront du vieux code ne pourront pas le passer sans migration dans le nouveau moteur si toute la liste est effectivement appliquée. Et franchement passer les ereg en preg ce n'est pas le pire. Du coup ce n'est pas dit que perdre du temps à faire le wrapper soit forcément pertinent.
> dejà livrer PHP sans Mysql
Si on veut être précis : depuis PHP 5 mysql n'est plus par défaut. Je ne suis même pas sûr que le client MySQL soit livré dans PHP 5.1.0 (on préfère le client externe à celui qui était builtin auparavant).
Ce n'est pas parce qu'il n'est pas dans le package par défaut que tu ne peux pas le compiler.
Ceci dit il me semble que tu as mal compris. Il ne s'agit pas de retirer le support de Mysql. Il s'agit de retirer une des extensions qui permet d'accéder à Mysql (et de laisser les autres : PDO et mysqli). Si on retire celle là c'est parce qu'elle ne supporte que mysql 3.23, qui commence à être de plus en plus vieux (il y a eu 3 versions majeures stables depuis : 4.0, 4.1 et 5.0, il y en aura probablement au moins une de plus d'ici PHP6). Les autres extensions permettent d'accéder au 3.23 mais aussi aux plus récentes.
> Et encore je ne trouve pas tres difficile de faire un tit
> require_once("general.inc.php"); au debut de chaque fichier.
Là aussi, n'y vois aucun mal, mais j'ai l'impression que tu ne connais pas la problématique.
La plupart des options dont on parle ce sont justement celles qui ne sont pas modifiables dans le script PHP lui même (register_globals, long_arrays, magic_quotes_gpc, ...)
De plus là où tu ne contrôles pas le .ini il est fréquent de ne pas avoir non plus accès à ini_set()
Et quand bien même tu as accès au .ini, tu vas avoir des problèmes quand telle lib te demande un "On" et telle autre un "Off". Ou plus bêtement quand ça te demande un "On" mais que c'est un risque de sécu non négligeable que tu voudrais éviter.
> C'est effectivement d'avantage une solution à base d'open_basedir et
> de forbiden_fonctions qui est utilisé par les hébergeurs. Si PHP6
> pouvait intégrer en plus directement un équivalent à suexec, ce serait
> parfait.
Ca n'est pas son rôle et ce n'est pas forcément réalisable.
Installé en module ce n'est pas faisable. Si le process apache-php change ses droits d'accès, il ne pourra pas retourner dans son utilisateur initial après et ne pourra pas être réutilisé.
Installé en CGI il y a déjà plein de wrapper de ce type. Suexec est fourni avec Apache mais il en existe d'autres moins couplés au serveur Web. Quel serait l'avantage pour PHP d'implémenter ça en interne ?
Désolé, je ne vois pas pourquoi un DM serait exclu du champ, et encore moins pourquoi Gnome n'intéresserait pas un "pro".
Il faudrait arrêter avec l'image de "linux uniquement pour les serveurs".
Pour un "pro" qui déploie du linux sur desktop, ça peut être utile aussi un paquet qui dépend de gnome.
Parce que ereg() est grosso modo 100x plus lent que preg_match(), et non, ce n'est pas un chiffre lancé au hasard.
L'idée jetée il y a longtemps c'était de supprimer la bibliothèque d'expressions rationnelles posix et de créer une extension dans PECL qui émule ereg() en transformant la syntaxe pour utiliser preg_match() en sous-main.
> suppression de mysql : c'est pas une bonne idée je trouve...
Parce que ?
> pour moi seuls les points 1 et 2 comptent, et encore c'est dejà
> desactivable...
Désactivable oui mais , est-ce désactivé ? le truc ce qu'on est obligés de faire 150 patchs à toutes les applications pour pouvoir livrer sur toutes les configurations possible.
C'est très pénible et pour les développeurs d'application, et pour les hébergeurs qui font le support, et pour les développeurs de PHP qui assurent la maintenance.
C'est d'autant plus pénible qu'on sait que certaines options sont mauvaises et font plus de mal que de bien, qu'elles n'auraient jamais du exister.
Ces options désactivables sont considérées comme obsolètes depuis longtemps, il est temps de les jeter et d'arrêter de se trainer des boulets toute la vie.
> Heu... Les paquets Debian tu peux les recomplier.
Tu peux. Le fais tu ? Non parce que "pouvoir" ne te protège en rien. C'est le faire qui peut éventuellement te protéger. Le fait est que tu ne le fais probablement pas, la plupart des gens non plus.
Et même en recompilant :
Avec quel compilateur ? qui te dit que les sources du compilateurs sont honnêtes et ne rajoutent pas la backdoor ?
Ok, tu peux vérifier les sources du compilateur et le recompiler, mais comme pour le recompiler tu auras toujours besoin d'un compilateur binaire tu l'as dans le ***
(et pour l'anecdote le coup du compilateur qui met une backdoor dans certains softs et qui rajoute le code malveillant quand il voit qu'il se recompile lui-même, c'est quelque chose qui a effectivement existé donc ce n'est pas totalement fictif).
Tu n'as que deux portes de sorties :
- décompiler pour voir que ça ressemble à ce que tu as comme source
- démarer d'un petit compilateur que tu as fait toi même en assembleur et qui te permet de compiler un compilateur plus gros, et ainsi de suite (en auditant les codes sources à chaque fois).
> Il n'y a pas énormement de monde qui le fait, mais si les binaires ne
> correspondaient pas au code source disponible on en entendrait
> parler très rapidement à mon avis !
Le fait est qu'on en entend parler de temps en temps de problèmes dans les sources, mais pas toujours si rapidement que ça. L'idée des millions de développeurs qui vérifient les sources c'est attirant mais largement illusoire.
En pratique si tu compromet sourceforge ou un dépot, que tu changes le source pendant quelques jours avant de remettre le bon, il y a peu de chances que ça se voit. Je ne parle même pas des malins qui mettent les bidouilles dans des fichiers "annexes" que peu de gens vérifient, comme les fichiers makefile et associés (cas de Xchat à mon souvenir).
Bref, avoir les sources ça aide, mais ce n'est pas la protection ultime que beaucoup pensent. Et globalement ça ne fonctionne de toutes façons que si on s'en sert.
> Par contre je ne comprend pas bien ce qu'implique le support natif
> d'unicode. On peut déjà utiliser unicode dans PHP non ?
oui et non.
Les chaines de caractères sont des suites d'octets. Oui tu peux mettre de l'unicode dedans. Non PHP ne saura pas que c'est de l'unicode et ne saura rien faire avec. Il ne saura que compter les octets et envoyer tout le binaire vers l'affichage.
Ce qu'on peut faire en plus avec une connaissance d'Unicode :
- trier par ordre alphabétique en prenant en compte autre chose que a-z et A-Z (les accents, les trémas, ß, etc.)
- connaitre le nombres de caractères (et pas d'octets)
- extraire des mots, des sous-chaînes
- mettre en majuscule/minuscule
> A un moment ou il est important que l'hébergement PHP soit
> compétitif par rapport à ASP, je pense que la suppression de
> safe_mode et open_basedir n'est vraiment pas une bonne chose.
Ils ne proposent pas de retirer open_basedir, c'est même limite l'inverse. Ils veulent retirer le safe_mode qui est dûr à maintenir et pose plein de problèmes pour les hébergeurs mutualisés (alors que c'est justement la cible) pour imposer plutot l'utilisation de open_basedir (qui n'agit pas sur les même choses mais qui répond assez bien au principal de la problématique).
> extension mysql: Il va falloir utiliser Mysqli ou PDO, dont l'utilisation
> n'est pas dutout la même.
L'utilisation de mysqli est (potentiellement) exactement la même que celle de l'extension mysql. A vrai dire, à part la procédure de connexion, il n'y a à mon souvenir qu'une seule fonction qui marche différement (qui renvoit NULL à la place de FALSE).
Certes, mysqli peut faire beaucoup plus de choses, va beaucoup plus loin, mais les suites de requêtes SQL et exploitation des résultats sont presques reprenables avec un rechercher/remplacer de mysql vers mysqli.
> D'ailleurs le choix se restreint à PDO puisque plus loin on vois ça:
> move "native" non pdo extensions to pecl.
L'idée de PECL c'est à la base uniquement de différencier le cycle de release de PHP de celui des extensions. Ca n'empeche même pas les packages PHP téléchageables de fournir de base les extensions concernées.
Rien n'empêche d'installer du PECL. C'est vraiment super simple. Un des buts c'est aussi le développement de PEAR et PECL. Personne ne se plaint d'avoir à utiliser CPAN au lieu d'avoir tout dans le paquet Perl de départ.
Quoi qu'il en soit, un des objectifs de ceux qui mettent en avant cette liste c'est justement de couper les vieux trucs qu'ils ne veulent plus maintenir et qu'ils considèrent comme une mauvaise idée.
Donc oui, il y a des choses qui ne marcheront plus avec les anciennes méthodes, et ils faudra utiliser les nouvelles.
> Est il vraiment nécessaire de supprimer tout ça ? Ne serait il pas
> plus bénéfique de changer la configuration par défaut afin de
> garder une compatibilité avec les applications existantes ?
C'est ce qui est fait pour l'instant et .. ça ne marche pas.
Les gens gardent les anciens php.ini. Au final on a toujours les problèmes de portabilité, de compatibilité, et on doit toujours supporter tous les systèmes "historiques" qu'on aimerait jeter.
Cette cassure on est beaucoup à l'attendre. Certains (dont moi) l'espéraient déjà pour PHP5, et malheureusement ils n'en ont pas profité.
> Au départ il s'agit de protéger les gens qui innovent.
Même pas, c'est encore mieux que ça.
Au départ le but c'est de révéler les secrets de conception pour qu'ils profitent à tous au lieu de vivre chez un ou deux artisants pour finir par mourrir avec le dernier détenteur.
Du coup on paye celui qui révèle le secret, et on lui offre un monopole pour que ça ne change rien pour lui à moyen terme.
Le but n'est même pas de financer la création, c'est de payer llibre circulation des idées existantes (bref, pile le contraire de l'effet actuel)
Marrant.
Dans un cas (LGPL/GTK) tu distribues ton code sous une licence libre qui assure un copyleft (même faible)
Dans un second cas (double licence proprio/GPL) tu donnes les droits sur ton code à quelqu'un pour qu'll le redistribue sous deux licences
Et tu cris que tu as plus de contrôle dans le second cas ? tu dois louper une marche là. La licence LGPL est certes ouverte mais elle l'est beaucoup moins que le "je donne mes droits sans contraintes à une société qui va renvendre tout ça en partie sous licence proprio".
Il est où ton contrôle dans le second cas ?
> Il peut servir de base à un logiciel qui sera ton code + une valeur
> ajoutée propriétaire
Le code que tu donnes à Trolltech pour intégration dans QT aussi.
> C'est faux. Tu peux autoriser quelqu'un à disposer du code que tu
> as produit, mais nul ne peut t'empêcher de redistribuer toi même
> ce code selon d'autres conditions.
Ouais, et demander à tout le monde de patcher l'arbre officiel avec tes modifs. Ca revient grosso modo à maintenir un fork.
Et pour que ce fork soit viable il faudra bien plus qu'une modif intéressante, parce que le jour où tu abandonnes trolltech tu perd la plupart des devs QT.
# mauvaise conclusion
Posté par Éric (site web personnel) . En réponse au journal HTTP -> http://www.w3.org : The best place to learn more about http ! (la vengeance). Évalué à 4.
> mais illustre tout de même les "tendances" du web.
Ben non puisque tu dis toi même qu'il y a eu une google bomb d'organisée pour associer w3c et http. Enfin tu ne le dis pas mais je le confirme puisque j'ai vu pas mal de blog le faire.
Reste après que les navigateurs et langages de programmation sont potentiellement sur-représentés puisqu'ils traitent potentiellement justement de HTTP ou du moins de protocoles et programmation réseau (Google tient compte des regroupements de ce type).
On peut même imaginer que la petite bombe (pas bien grosse, il est vrai), associée à une actu HTTP quelconque au même moment sur des sites libres, ait pu faire créer à Google un groupe de site orienté "logiciel libre et programmation".
Bref, aucune chance d'y récupérer même des tendances ou des conclusions comme les tiennes.
[^] # Re: SMS
Posté par Éric (site web personnel) . En réponse au journal 30 SMS gratuits ... grace à un soft GPL. Évalué à 5.
Même si on se limite aux portables, on met en comparaison 30 messages courts avec 20 minutes de conversation, alors qu'un message court ne doit pas prendre plus de 5s (à tout casser) pour l'envoi/reception et qu'il n'a aucune assurance de qualité de service.
C'est encore plus monstrueux quand je vois qu'on peut téléphoner 3 fois plus longtemps au Brésil que sur un portable. Quelqu'un m'explique ?
[^] # Re: Pendant les fêtes de fin d'année..
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à 6.
Ici dès qu'on conteste un point d'argumentation on a l'impression de passer pour le grand méchant de service qui rejette tout le fond en bloc.
Mis à part ta première phrase (*) je ne vois pas à quoi répond tout le reste.
Pour faire clair : oui je suis furieusement contre ce projet de loi qui me semble très mauvais et dangereux. Voilà, c'est clair comme ça ?
* (effectivement une loi qui cherche à interprété les intentions est dangereuse on est d'accord, mais à ce moment là c'est ça qu'il faut critiquer, et pas dire que la loi interdit tout alors que c'est faux ; c'est uniquement ça que je reproche)
[^] # Re: Mouai
Posté par Éric (site web personnel) . En réponse à la dépêche Le Linux Standard Base devient une norme ISO. Évalué à 3.
> machines ayant besoin de logiciels au dessus qui n'existent pas en libre, de
> logiciels qui interesseraient au maximum 100 entreprises dans le monde
Donc on a le choix de parler standardisation pour :
- 100 entreprises dans le monde
- les PME
- les particuliers
S'il y a bien un domaine qui me parait hors propos c'st celui de ta superbe entreprise avec des contraintes et des logiciels qui ne concernent que 100 entreprises dans le monde.
Eux ont largement les moyens d'adapter une fois leur logiciel pour qu'il passe sur leur nombreuses installations, ou de faire de la personalisation sur la machine s'il n'y en a qu'une, ou même de demander une adaptation à l'éditeur.
Je ne sais pas si ta superbe entreprise avec tes contraintes pas possible est réelle ou pas mais peu importe. Pour le coup on ne normalise pas toutes les distribs rien que pour les 100 boites concernées. Non, la normalisation l'intérêt c'est justement pour les autres, la masse, ceux qui n'ont pas les moyens de faire autrement.
> Bref, faudrait peut-etre aller voir autre chose que des PME, tu verras que les
> besoins ne sont pas les meme, qu'il y a plein de contrainte ssur les installations
> (une seule distribution autorisée si et seulement si elle est configurée de telle
> manière par exemple), qui font que tu ne peux pas faire ce que tu veux, et c'est
> la que la LSB sert.
Ah ? s'il n'y a qu'une seule distrib, sur laquelle on n'installe que des choses certifiées, on s'en fout un peu de savoir si elle est LSB ou pas hein.
La LSB elle sert justement pour compatibilité quand tu veux supporter plusieurs distrib. Enfin je dis ça, j'ai peut être mal compris un truc mais bon ...
C'est marrant mais ton post me donne largement envie de penser le contraire de toi à propos de QT
[^] # Re: Pendant les fêtes de fin d'année..
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à 1.
> informations sur le sujet ne semble "pas destinée à alterer le
> fonctionnement d'une mesure de protection."
Là je vais accepter de me faire traiter de naif, mais je pense les juges suffisament intelligents pour faire la différence entre quelqu'un qui publie un avis de sécurité et quelqu'un qui met une suite de crack sur sa page avec un "disclaimer: le contenu de ce site est là pour éducation et pas pour être utilisé".
Toujours est-il que les articles dont on parle ne sont pas des exceptions à une règle générale, c'est donc au plaignant d'apporter suffisament d'éléments à charge pour convaincre le juge que tu ton but était bel et bien la mise en défaite des systèmes de protections.
> Ou est la limite ? N'est-ce pas évident que l'information d'une
> faiblesse peut servir pour l'exploiter ?
Globalement similaire à un "le coup est parti tout seul" et un "je l'ai visé", à la diffamation (qui parle d'intention de nuire), et à pleins de trucs dans la loi qui parlent d'intention, de volonté ou de "consciement". C'est au juge de trancher de bonne foi.
Parfois c'est effectivement limite, il peut effectivement y avoir des ereurs, mais je ne pense pas qu'il soit bon de confondre le "destiné à" et le "permet de", ou de laisser entendre que c'est la même chose.
Si on ne fait pas nous même la distinction ce sont les gens à qui on s'adresse qui vont la faire et nous retourner un "on continue avec ce projet de loi, visiblement vous n'avez pas compris"
[^] # Re: On peut rajouter
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à 6.
[^] # Re: Pendant les fêtes de fin d'année..
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à 3.
fournir un service ou une information destinés à faciliter ou à permettre [...]
et de rappeler à quoi je répond :
Si personne n'est autorisé à travailler ou communiquer sur la sécurité des systèmes, ca limite les corrections de failles de sécurité.
Tu peux travailler sur la sécurité, communiquer sur ce que tu fais si ta communication n'est pas destinée à alterer le fonctionnement d'une mesure de protection.
Ta communication ou ton travail peuvent être destinés (entre autres) à :
- informer sur la faible sécurité de ces systèmes
- améliorer la sécurité de ces systèmes
- détailler la sécurité dans un but de formation
- corriger les problèmes de sécurité ou fonctionnement de ces systèmes
Bref, le projet de loi vise l'intention et le but, pas l'effet et les possibilités. Ca ne t'empêche nullement de travailler ou communiquer sur la sécurité de ces systèmes, ni de publier des corrections.
Oui c'est une "information" (ton emphase), mais non, elle n'est pas destinée à contourner les mesures de protection (mon emphase), donc elle n'est pas visée par le 3° que tu cites.
La seule chose que ça t'interdit c'est de dire "bon, je vais vous aider à casser les systèmes parce que j'ai vu une faille de sécurité, voilà comment il faut faire ...".
Je trouve totalement crétin et mauvais de pénaliser le contournement d'une protection et pas le délit réel que la protection souhaite empêcher, ça ouvre trop de dérapages possibles et trop de cas couverts alors qu'ils ne le devraient pas.
Par contre non, ça ne t'empêche pas de faire de la recherche en sécurité, de faire du logiciel libre ou d'étudier/commenter ces dispositifs. Du moins pas d'après ma lecture.
[^] # Re: Pendant les fêtes de fin d'année..
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à 4.
> deviendra "oui" parceque leurs avocats seront plus forts, plus
> nombreux, plus tout.
Pour faire des pressions ou des procès à gogo sans fondement légal et uniquement grace à la pression judiciaire et des avocats, ils n'ont pas besoin de loi (puisque sans fondement légal)
La loi elle même ne te retreint pas la dessus. Certes d'aucun peuvent faire peur avec , mais ils n'ont pas attendu ce projet pour faire peur. Il y a plein de lois qu'on peut faire semblant de mal interpréter.
Bref, on est en train de reprocher à la loi d'interdire des choses qu'elle n'interdit pas. Ca ne me parait pas cohérent (il y a suffisament de choses qu'elle interdit et qui sont mauvaises pour ne pas en inventer) ni intelligent (je vois bien les réponses "vous n'avez pas compris" qu'ils feront, et avec raison puisqu'on argumente de travers)
> Cette loi est une saloperie qui nous empêchera, au regard de la loi,
> de faire à peu près tout ce qu'on fait actuellement avec nos ordis...
Je ne sais pas ce que tu fais avec ton ordi, je suis d'accord avec toi que ce projet de loi est une saloperie, mais une grosse partie (de ce dont on parle ici) n'est justement pas empêchée "au regard de la loi". C'est justement le fond de mon intervention.
[^] # Re: La révolution !
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à -1.
Le décrêt parle bien d'une autorisation mais de ce que j'en comprend (la flemme de suivre les n° de loi) ça doit se référer à d'autres réglementations tout à fait indépendantes : plan de vol, zones habituellement interdites au survol (militaires, aglomérations, ...), hauteur au sol du vol. bref, des choses qui sont déjà réglementées (pour des bonnes raisons). Je n'y vois pas d'autorisation de prise de vue.
Je peux faire une erreur (vu que j'ai pas fait l'effort d'aller lire la loi de départ qui a été modifiée ni les références données des articJe ne lis pas la même chose. Où vois tu qu'il faut demander l'autorisation ? moi je lis dans l'arrêté qu'il faut faire une déclaration préalable, ce qui n'a un peu rien à voir : la déclaration n'implique pas de réponse ou refus/acceptation par le destinataire.
Le décrêt parle bien d'une autorisation mais de ce que j'en comprend (la flemme de suivre les n° de loi) ça doit se référer à d'autres réglementations tout à fait indépendantes : plan de vol, zones habituellement interdites au survol (militaires, aglomérations, ...), hauteur au sol du vol. bref, des choses qui sont déjà réglementées (pour des bonnes raisons). Je n'y vois pas d'autorisation de prise de vue.
Je peux faire une erreur (vu que j'ai pas fait l'effort d'aller lire la loi de départ qui a été modifiée ni les références données des articles de loi connexes), mais ce qui me parait grave moi ça serait surtout de faire dire de telles choses à une loi qui ne les dit pas du tout, et de s'en servir dans une argumentation.les de loi
[^] # Re: Pendant les fêtes de fin d'année..
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à 0.
Peut importe que ça altère. La question c'est plus : est-ce que c'était le but ? Ce projet de loi ne concerne que les cas où tu dis "oui".
Ca ne t'empêche pas d'en parler, de l'étudier, ou même de détailler ce mécanisme et ces faiblesses. Enfin uniquement si *ton but est* de les contourner et d'en altérer le fonctionnement.
[^] # Re: Pendant les fêtes de fin d'année..
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à -2.
Je serai tenté de dire *FUD*
Ce qui est interdit c'est de faire une comm ou une action, en vue d'altérer la protection.
On parle du but de l'action, du logiciel ou de la communication, pas de ce qu'il peut faire. Si ta recherche ou ta comm a pour but d'informer des limitations de ces protections, de leurs effets, d'éduquer ou de former sur leur fonctionnement, d'en corriger la sécurité ou améliorer le fonctionnement .... il n'y a rien (que j'ai vu) qui t'en interdit.
(attention, ça ne veut pas dire que ce projet est bon, mais si on veut être crédibles pour bloquer ce qui pose problème il faut évityer de faire du *FUD* et parler de problèmes imaginaires, il y en a assez de réels comme ça).
# à ceux qui ralent
Posté par Éric (site web personnel) . En réponse à la dépêche EUCD/DADVSI : des contrefacteurs partout ?. Évalué à 3.
Militer pour ne pas avoir du tout de projet de loi et tout rejeter en bloc ne fonctionnera probablement pas. Ils sont fondés à faire un projet de loi sur ce sujet et ils en ont même l'obligatoire (transposition de l'EUCD).
Par contre, ce qui me parait plus constructif de proposer des améliorations pour que ce projet ne fasse pas tout le mal qu'on y voit. Ca me parait aussi beaucoup plus réaliste à obtenir :
- faire rejeter les articles qui négatifs qui ont été ajoutés depuis l'EUCD
- ajouter des exceptions ou renforcer les existantes pour ne pas totalement déséquilibrer les droits d'auteurs
- ajouter des mécanismes pour protéger l'utilisateur d'un monopole ou d'un contrôle de ses propres systèmes par les mesures de protection (en gros mettre dans la loi un truc contre "l'informatique de confiance") ou ajouter une limitation ne protégeant que les protections qui ne créent pas une dépendance ou un subbordination des utilisateurs aux producteurs
- ajouter une exception pour permettre l'intéropérabilité (plus explicite et forte que celle qui est présente dans ce projet de loi)
- ajouter une exception pour permettre la relecture d'oeuvres acquises de manière licite
- ajouter un mécanisme pour empecher que les mesures de protection des droits d'auteurs deviennent des manières de verrouiller les droits des utilisateurs et concurrents (cf l'affaire des cartouches lexmark)
- dépénaliser tout contournement qui n'a pas pour effet ou pour but la violation des droits d'auteurs (la protection des droits d'auteurs est le seul but de cette loi, donc ça ne devrait pas couvrir autre chose)
etc.
Ca me parait pouvoir avoir un effet bien plus grand et efficace que le simple rejet en bloc.
[^] # Re: comme php4
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 3.
[^] # Re: safe_mode -> open_basedir
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 1.
Parce que ça veut dire rajouter dans PHP un code qui n'a rien à voir avec le langage de programmation, qui est très sensible coté sécurité, et qui de plus risque de ne pas être portable aussi bien que PHP (il faut au minimum un ifdef pour windows)
Avoir plusieurs softs, chacun avec un role et une fonction définie c'est bien. Les gros trucs monolithyques qui font le café c'est inmaintenable assez vite.
> Suexec ne permet absolument pas de remplir ce rôle.
> Et s'il en existe d'autres, il n'en existe pas tant que ça non plus.
Il le tient pourtant à plein d'endroits. Ca doit être le wrapper le plus utilisé pour ça. Pourquoi ne pourrait-il pas convenir d'après toi ?
Et s'il n'en existe pas des centaines d'autres il doit bien en exister 3 ou 4 de courants, ce qui est largement assez pour un soft de ce type.
> De permettre d'avoir un système sécurisé sans devoir rajouter quoi
> que ce soit d'autre.
Tu rajoutes bien apache, tu rajoutes l'OS, tu rajoutes les libs, tu rajoutes tes comptes utilisateur ... PHP ne contient pas tout et n'est pas fait pour ça. Pourquoi vouloir intégrer suexec et pas directement le serveur Web par exemple ?
C'est un langage de programmation, pas un serveur d'application, et encore moins une plate-forme complète.
[^] # Re: ereg ?
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 2.
Les fonctions mysql_* vont peut être disparaitre. Maintenant :
- tu auras des mysqli_* qui fonctionneront quasiment pareil, il suffit de faire un rechercher/remplacer et corriger un ou deux détails (la phase connexion entre autres)
- rien ne t'empêche de compiler toi même l'extension mysql sur ta version de PHP, ou d'utiliser une bibliothèque qui reprend les fonctions mysql pour les diriger vers mysqli
Bref, c'est plus clean pour PHP mais ça ne te retire pas grand chose. De toutes façons d'ici que ce PHP6 sorte il est peu probable que tu utilises encore du mysql 3.23 donc de toutes façons les fonctions mysql_* actuelles n'auraient pas fonctionné.
> vu que sur une de mes machines j'ai un mysql 4.0.17 qui tourne et que je continue
> a utilise les fameuses fonction mysql_* je me dis que vos post en sont pas sur la
> même longueur d'onde
Oui, en fait je prend un raccourci. La cassure n'est pas sur 3.23 / 4.0 mais sur 4.0.x / 4.0.y, je ne me souviens plus exactement où.
Il y a aussi des gens qui utilisent les mysql_* avec mysql 4.1 et > mais c'est au prix d'une bidouille (une config spéciale du serveur mysql qui lui demande d'utiliser les anciens protocoles d'authentification)
> vu que le changement n'est applicable que pour le temps ou le fichier est traité,
> j'etais (je le suis encore) convaincu qu'on pouvait utiliser ini_set() pour mettre
> les register global a off, ainsi que les magic_quotes.
Non, parce que quand il lit ton fichier, il a déjà initialisé (ou pas) les globales, et a déjà opéré (ou pas) l'échappement des magic_quotes_gpc.
> moi, perso... la suppression de mysql, c'est putot une decission politique non ?
> (licence GPL)... faut-il s'en rejuire ?
C'est effectivement à l'origine une décision politique, mais pas du groupe PHP. Ca vient du groupe Mysql.
En gros l'ancien client Mysql était typé LGPL ou BSD (je ne sais plus) pour qu'une appli non compatible GPL puisse se connecter à un serveur Mysql.
Ils ont voulu restreindre un peu plus et le nouveau client à partir de mysql 4.0 (celui qui permet de se connecter à mysql 4.1) est GPL uniquement. Pour que les gens ne continuent pas à utiliser l'ancien client ils ont changé le système d'authentification (ou plus précisément le cryptage des mots de passe). On créé l'incompatibilité pour forcer la mise à jour, donc la nouvelle licence, donc le paiement de la licence proprio pour ceux chez qui ça ne convient pas.
Le premier défaut c'est qu'on se retrouve avec deux clients mysql différents. Ca explique qu'on ait maintenant deux extensions "mysql" et "mysqli". Le second défaut c'était que l'extension "mysql" était fournie par défaut avant. On ne peut pas faire la même chose avec "mysqli" parce que si PHP est du logiciel libre (assez proche de BSD), ce n'est pas du logiciel compatible GPL. (note; ce problème de licence a été réglé depuis)
Donc oui, c'est bourré de politique là dedans. Mais bon, c'est comme ça.
> mysqli aurat'il des perfs comparable ?
oui
> faudrat'il se payer le code des appli php pour changer les appels de mysql ?
Non si tu contrôles ton serveur, tu peux le bidouiller pour te connecter avec l'ancien client (utiliser l'ancien cryptage des mots de passe)
Oui sinon, mais les modifs à faire sont assez simples.
Maintenant on parle de PHP6, qui au mieux sortira en décembre 2006 (au mieux). Aujourd'hui, un an et demi après PHP 5.0, 95% des gens sont encore en PHP4.
Autant dire que rien ne t'obligera à être en PHP6 à ce moment là, donc à changer quoi que ce soit à ton code.
[^] # Re: comme php4
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 2.
Certes, strlen() fonctionnera sur les chaînes UTF8
Mais ceux qui utilisaient strlen() pour calculer le nombre d'octets (ils sont nombreux vu qu'il n'y avait que ça pour le faire) auront des problèmes. Si tout le code PHP qui tourne n'est pas le tien tu risques des ennuis.
Pire, ça essayera de jouer avec l'UTF8 dans tes champs binaires, types les fichiers compressés. C'est dommage et ça peut casser certaines choses (impossible de retirer les X derniers octets d'un flux binaire opaque).
A partir du moment où tu ne codes que pour mbstring, c'était mieux de le faire explicitement. Tu ne pourris pas tout ce qui cherche à calculer des nombre d'octets, et ça fonctionnera chez ceux qui ont mbstring sans avoir activé l'overload.
De toutes façons chez ceux qui n'ont pas mbstring l'appli aurait buggué donc autant que ça plante en ralant sur mbstring, c'est même presque mieux.
L'overload mbstring c'est à restreindre à des cas très précis. Par exemple l'internationalisation "en catastrophe" d'une appli qui n'était pas prévue pour.
[^] # Re: ereg ?
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 3.
> si non : pas uen bonen idée de supprimer car ca casse tout.
> si oui, il suffit de faire un wrap entre les 2 fonctions.
> conclusion : pas la peien de supprimer .
Non, ce n'est pas la même syntaxe.
Ceci dit si tu ne sais pas ça (c'est à dire que tu n'as aucune connaissance sur le sujet), et dit vraiment sans aucune agressivité ni aucun reproche, je ne suis pas sûr qu'exprimer un avis avant de te documenter soit forcément pertinent.
Pour le wrapp c'est justement ce qui a été proposé un temps (cf le commentaire auquel tu répond). Reste à voir si ça vaut le coup, si beaucoup de gens ont du ereg() difficile à passer en preg().
De toutes façons les gens qui auront du vieux code ne pourront pas le passer sans migration dans le nouveau moteur si toute la liste est effectivement appliquée. Et franchement passer les ereg en preg ce n'est pas le pire. Du coup ce n'est pas dit que perdre du temps à faire le wrapper soit forcément pertinent.
> dejà livrer PHP sans Mysql
Si on veut être précis : depuis PHP 5 mysql n'est plus par défaut. Je ne suis même pas sûr que le client MySQL soit livré dans PHP 5.1.0 (on préfère le client externe à celui qui était builtin auparavant).
Ce n'est pas parce qu'il n'est pas dans le package par défaut que tu ne peux pas le compiler.
Ceci dit il me semble que tu as mal compris. Il ne s'agit pas de retirer le support de Mysql. Il s'agit de retirer une des extensions qui permet d'accéder à Mysql (et de laisser les autres : PDO et mysqli). Si on retire celle là c'est parce qu'elle ne supporte que mysql 3.23, qui commence à être de plus en plus vieux (il y a eu 3 versions majeures stables depuis : 4.0, 4.1 et 5.0, il y en aura probablement au moins une de plus d'ici PHP6). Les autres extensions permettent d'accéder au 3.23 mais aussi aux plus récentes.
> Et encore je ne trouve pas tres difficile de faire un tit
> require_once("general.inc.php"); au debut de chaque fichier.
Là aussi, n'y vois aucun mal, mais j'ai l'impression que tu ne connais pas la problématique.
La plupart des options dont on parle ce sont justement celles qui ne sont pas modifiables dans le script PHP lui même (register_globals, long_arrays, magic_quotes_gpc, ...)
De plus là où tu ne contrôles pas le .ini il est fréquent de ne pas avoir non plus accès à ini_set()
Et quand bien même tu as accès au .ini, tu vas avoir des problèmes quand telle lib te demande un "On" et telle autre un "Off". Ou plus bêtement quand ça te demande un "On" mais que c'est un risque de sécu non négligeable que tu voudrais éviter.
[^] # Re: safe_mode -> open_basedir
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 3.
> de forbiden_fonctions qui est utilisé par les hébergeurs. Si PHP6
> pouvait intégrer en plus directement un équivalent à suexec, ce serait
> parfait.
Ca n'est pas son rôle et ce n'est pas forcément réalisable.
Installé en module ce n'est pas faisable. Si le process apache-php change ses droits d'accès, il ne pourra pas retourner dans son utilisateur initial après et ne pourra pas être réutilisé.
Installé en CGI il y a déjà plein de wrapper de ce type. Suexec est fourni avec Apache mais il en existe d'autres moins couplés au serveur Web. Quel serait l'avantage pour PHP d'implémenter ça en interne ?
[^] # Re: Mouais
Posté par Éric (site web personnel) . En réponse à la dépêche Le Linux Standard Base devient une norme ISO. Évalué à 3.
Il faudrait arrêter avec l'image de "linux uniquement pour les serveurs".
Pour un "pro" qui déploie du linux sur desktop, ça peut être utile aussi un paquet qui dépend de gnome.
[^] # Re: ereg ?
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 2.
Parce que ereg() est grosso modo 100x plus lent que preg_match(), et non, ce n'est pas un chiffre lancé au hasard.
L'idée jetée il y a longtemps c'était de supprimer la bibliothèque d'expressions rationnelles posix et de créer une extension dans PECL qui émule ereg() en transformant la syntaxe pour utiliser preg_match() en sous-main.
> suppression de mysql : c'est pas une bonne idée je trouve...
Parce que ?
> pour moi seuls les points 1 et 2 comptent, et encore c'est dejà
> desactivable...
Désactivable oui mais , est-ce désactivé ? le truc ce qu'on est obligés de faire 150 patchs à toutes les applications pour pouvoir livrer sur toutes les configurations possible.
C'est très pénible et pour les développeurs d'application, et pour les hébergeurs qui font le support, et pour les développeurs de PHP qui assurent la maintenance.
C'est d'autant plus pénible qu'on sait que certaines options sont mauvaises et font plus de mal que de bien, qu'elles n'auraient jamais du exister.
Ces options désactivables sont considérées comme obsolètes depuis longtemps, il est temps de les jeter et d'arrêter de se trainer des boulets toute la vie.
[^] # Re: et là on dit...
Posté par Éric (site web personnel) . En réponse au journal Sony, rootkit et WoW. Évalué à 3.
Tu peux. Le fais tu ? Non parce que "pouvoir" ne te protège en rien. C'est le faire qui peut éventuellement te protéger. Le fait est que tu ne le fais probablement pas, la plupart des gens non plus.
Et même en recompilant :
Avec quel compilateur ? qui te dit que les sources du compilateurs sont honnêtes et ne rajoutent pas la backdoor ?
Ok, tu peux vérifier les sources du compilateur et le recompiler, mais comme pour le recompiler tu auras toujours besoin d'un compilateur binaire tu l'as dans le ***
(et pour l'anecdote le coup du compilateur qui met une backdoor dans certains softs et qui rajoute le code malveillant quand il voit qu'il se recompile lui-même, c'est quelque chose qui a effectivement existé donc ce n'est pas totalement fictif).
Tu n'as que deux portes de sorties :
- décompiler pour voir que ça ressemble à ce que tu as comme source
- démarer d'un petit compilateur que tu as fait toi même en assembleur et qui te permet de compiler un compilateur plus gros, et ainsi de suite (en auditant les codes sources à chaque fois).
> Il n'y a pas énormement de monde qui le fait, mais si les binaires ne
> correspondaient pas au code source disponible on en entendrait
> parler très rapidement à mon avis !
Le fait est qu'on en entend parler de temps en temps de problèmes dans les sources, mais pas toujours si rapidement que ça. L'idée des millions de développeurs qui vérifient les sources c'est attirant mais largement illusoire.
En pratique si tu compromet sourceforge ou un dépot, que tu changes le source pendant quelques jours avant de remettre le bon, il y a peu de chances que ça se voit. Je ne parle même pas des malins qui mettent les bidouilles dans des fichiers "annexes" que peu de gens vérifient, comme les fichiers makefile et associés (cas de Xchat à mon souvenir).
Bref, avoir les sources ça aide, mais ce n'est pas la protection ultime que beaucoup pensent. Et globalement ça ne fonctionne de toutes façons que si on s'en sert.
[^] # Re: comme php4
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 5.
> d'unicode. On peut déjà utiliser unicode dans PHP non ?
oui et non.
Les chaines de caractères sont des suites d'octets. Oui tu peux mettre de l'unicode dedans. Non PHP ne saura pas que c'est de l'unicode et ne saura rien faire avec. Il ne saura que compter les octets et envoyer tout le binaire vers l'affichage.
Ce qu'on peut faire en plus avec une connaissance d'Unicode :
- trier par ordre alphabétique en prenant en compte autre chose que a-z et A-Z (les accents, les trémas, ß, etc.)
- connaitre le nombres de caractères (et pas d'octets)
- extraire des mots, des sous-chaînes
- mettre en majuscule/minuscule
# safe_mode -> open_basedir
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 5.
> compétitif par rapport à ASP, je pense que la suppression de
> safe_mode et open_basedir n'est vraiment pas une bonne chose.
Ils ne proposent pas de retirer open_basedir, c'est même limite l'inverse. Ils veulent retirer le safe_mode qui est dûr à maintenir et pose plein de problèmes pour les hébergeurs mutualisés (alors que c'est justement la cible) pour imposer plutot l'utilisation de open_basedir (qui n'agit pas sur les même choses mais qui répond assez bien au principal de la problématique).
> extension mysql: Il va falloir utiliser Mysqli ou PDO, dont l'utilisation
> n'est pas dutout la même.
L'utilisation de mysqli est (potentiellement) exactement la même que celle de l'extension mysql. A vrai dire, à part la procédure de connexion, il n'y a à mon souvenir qu'une seule fonction qui marche différement (qui renvoit NULL à la place de FALSE).
Certes, mysqli peut faire beaucoup plus de choses, va beaucoup plus loin, mais les suites de requêtes SQL et exploitation des résultats sont presques reprenables avec un rechercher/remplacer de mysql vers mysqli.
> D'ailleurs le choix se restreint à PDO puisque plus loin on vois ça:
> move "native" non pdo extensions to pecl.
L'idée de PECL c'est à la base uniquement de différencier le cycle de release de PHP de celui des extensions. Ca n'empeche même pas les packages PHP téléchageables de fournir de base les extensions concernées.
Rien n'empêche d'installer du PECL. C'est vraiment super simple. Un des buts c'est aussi le développement de PEAR et PECL. Personne ne se plaint d'avoir à utiliser CPAN au lieu d'avoir tout dans le paquet Perl de départ.
Quoi qu'il en soit, un des objectifs de ceux qui mettent en avant cette liste c'est justement de couper les vieux trucs qu'ils ne veulent plus maintenir et qu'ils considèrent comme une mauvaise idée.
Donc oui, il y a des choses qui ne marcheront plus avec les anciennes méthodes, et ils faudra utiliser les nouvelles.
> Est il vraiment nécessaire de supprimer tout ça ? Ne serait il pas
> plus bénéfique de changer la configuration par défaut afin de
> garder une compatibilité avec les applications existantes ?
C'est ce qui est fait pour l'instant et .. ça ne marche pas.
Les gens gardent les anciens php.ini. Au final on a toujours les problèmes de portabilité, de compatibilité, et on doit toujours supporter tous les systèmes "historiques" qu'on aimerait jeter.
Cette cassure on est beaucoup à l'attendre. Certains (dont moi) l'espéraient déjà pour PHP5, et malheureusement ils n'en ont pas profité.
[^] # Re: La seule solution
Posté par Éric (site web personnel) . En réponse à la dépêche Création de l'Open Invention Network (OIN). Évalué à 10.
Même pas, c'est encore mieux que ça.
Au départ le but c'est de révéler les secrets de conception pour qu'ils profitent à tous au lieu de vivre chez un ou deux artisants pour finir par mourrir avec le dernier détenteur.
Du coup on paye celui qui révèle le secret, et on lui offre un monopole pour que ça ne change rien pour lui à moyen terme.
Le but n'est même pas de financer la création, c'est de payer llibre circulation des idées existantes (bref, pile le contraire de l'effet actuel)
[^] # Re: C'était prévisible
Posté par Éric (site web personnel) . En réponse au journal Quelque chose de malsain dans le monde du desktop libre. Évalué à 3.
Dans un cas (LGPL/GTK) tu distribues ton code sous une licence libre qui assure un copyleft (même faible)
Dans un second cas (double licence proprio/GPL) tu donnes les droits sur ton code à quelqu'un pour qu'll le redistribue sous deux licences
Et tu cris que tu as plus de contrôle dans le second cas ? tu dois louper une marche là. La licence LGPL est certes ouverte mais elle l'est beaucoup moins que le "je donne mes droits sans contraintes à une société qui va renvendre tout ça en partie sous licence proprio".
Il est où ton contrôle dans le second cas ?
> Il peut servir de base à un logiciel qui sera ton code + une valeur
> ajoutée propriétaire
Le code que tu donnes à Trolltech pour intégration dans QT aussi.
> C'est faux. Tu peux autoriser quelqu'un à disposer du code que tu
> as produit, mais nul ne peut t'empêcher de redistribuer toi même
> ce code selon d'autres conditions.
Ouais, et demander à tout le monde de patcher l'arbre officiel avec tes modifs. Ca revient grosso modo à maintenir un fork.
Et pour que ce fork soit viable il faudra bien plus qu'une modif intéressante, parce que le jour où tu abandonnes trolltech tu perd la plupart des devs QT.