Bruno a écrit 270 commentaires

Bah, PHP c'est has-been, les stagiaires ne font plus que du node.js maintenant.

La version de PHP chez free est toujours la 5.1.3RC4

La mise à jour automatique a subrepticement fonctionné chez free il y a 3 ans, quand on a fait des pieds et des mains auprès de free pour qu'ils mettent en whitelist le site de dotclear dans les url autorisées.

Depuis, cette whitelist semble avoir disparu et donc les connexions distantes depuis PHP chez free sont fermées…

En attendant, il est recommandé de rester sur la version 2.5.3 de dotclear chez free, le prérequis pour la 2.6 étant PHP 5.2.

pour moi c'est malheureusement le syndrome classique du projet techniquement bon mais visiblement sans vision marketing (séduire les utilisateurs/contributeurs potentiels, prendre des parts de marché, se mesurer aux concurrents, etc, etc)

Pas la peine de chercher si loin les explications : une communauté d'utilisateurs ne suffit pas à faire vivre un projet, il faut aussi une communauté de développeurs. Dotclear n'a besoin ni d'argent, ni de marketing, il a juste besoin de contributeurs qui ont du temps à y consacrer…

A noter, une vidéo de Paul Irish, membre de la team jQuery, où il évoque les 10 choses qu'il a retenues du code source de jQuery.

On y apprend pas mal de choses intéressantes, qui sont même parfois plus des informations sur javascript que jQuery.

La vidéo est visible sur son blog : http://paulirish.com/2010/10-things-i-learned-from-the-jquer(...)

--- magic_quotes_gpc = on

Pas sûr que mettre magic_quotes_gpc à on soit une bonne solution : la plupart des applis php existantes blindent déjà les échappements des requêtes, et activer le magic_quotes_gpc introduira des effets de bord importants. Cette option est d'ailleurs obsolète depuis php 5.3.

Coté parades, il y a aussi l'installation de mod_security. Il faut en revanche passer un certain temps à posteriori pour supprimer les règles un peu trop extrêmes...

Outre les très bon conseils déjà donnés, il peut y avoir un point sensible, pas forcément lié ni à Apache, ni à PHP, mais directement à FTP.

En effet, depuis quelques temps sévissent un certain nombre de trojans qui se contentent de capturer les login/password qui transitent sur des flux ftp. Dans certains cas, les informations capturées sont uploadées sur un serveur distant. Il ne reste plus aux utilisateurs malveillants que de sniffer les espaces FTP ainsi récupérés, et injecter leur code dans tous les index.php trouvés, souvent un iframe qui contient un lien vers un SWF infecté.

C'est un sujet qui revient souvent sur les forums des hébergeurs, et il n'est pas aisé d'y remédier. Je suis tombé sur ce site qui évoque le déroulement de l'attaque : http://www.lepotlatch.org/index.php/post/2009/04/22/Mon-site(...)

Donc, pour sécuriser un peu plus le site :
* Recommander à ses utilisateurs d'avoir des logiciels de protection à jour
* Filtrer les IP ayant accès au FTP
* Eventuellement passer au sftp, en espérant que les trojans n'évoluent pas trop vite...

Ca, pour être court ...

The page cannot be displayed because an internal server error has occurred.


Et si ça permettait de promouvoir les logiciels libres différemment, justement ?

Pour "vendre" du LL, plutôt que des CD d'installation ou des live-cd sur des présentoirs, assez chers à produire, et obsolètes à la première mise à jour, pourquoi ne pas proposer des bornes en libre service dans les grande surfaces, à la manière des postes à développement de photos numériques ?
* L'utilisateur arrive avec sa clef USB / sa carte SD
* Il y uploade les logiciels qu'il choisit sur la borne. Cela peut inclure des logiciels libres ou gratuits
* Tout le monde peut y trouver son compte. Les grandes surfaces vendent des supports de stockage à coté de la borne pour les étourdis, les éditeurs y mettent les versions d'évaluation de leur produit, et le libre peut trouver sa place

Tu as un lien 'English' en haut à droite de la page :)

... ça fait presque 2 mois qu'il est mort : http://fr.wikipedia.org/wiki/Carlos_(chanteur)

SVN 1.5 permet(tra) de gérer plusieurs changesets en local, par le biais de changelists : http://blogs.open.collab.net/svn/2007/07/one-quality-of-.htm(...)

Ca veut dire qu'ils vont tout devoir redévelopper from scratch ? /o\

Sur Symbian on en trouve aussi. Voir les nokia E65 et N95.

Puisqu'on a a priori enfin trouvé le remède à tous les maux, j'en déduis que la taxe sur les média de stockage n'a plus lieu d'être, si ?

... à se faire attaquer en justice par Gillette, ça ...

Pour ma part, je suis passé en mode pubkey only, avec mes clefs sur ma clef usb personnelle.
Du coup, non seulement les kiddies ont très très peu de chances de tomber par hasard sur un bon mot de passe, mais en plus ils sont très facilement désactivables via denyhosts...

Pour ma part, pour déclencher des actions sur certaines lignes dans les logs, j'utilise swatch, et dès que j'ai un "invalid user" détecté, l'ip de l'utilisateur est ajoutée dans les ip à rejeter.

Un tuto est disponible ici (adaptable pour pas mal d'OS je suppose, ça fonctionne très bien sur debian, et j'imagine aussi sur BSD): http://gentoo-wiki.com/HOWTO_Protect_SSHD_with_Swatch

D'un autre coté, pourquoi les hébergeurs passeraient-ils aujourd'hui en php5, vu que presque personne ne fait d'applications spécifiquement en php5 ? C'est une question qui paraît bête au premier abord, mais en y réfléchissant bien, la majorité des applis php existantes (CMS, forums, ...) se contentent très bien de php4.

C'est un peu un cercle vicieux : les développeurs ne font pas leurs applis en php5, parce que peu d'hébergeurs supportent php5, et les hébergeurs ne passent pas en php5 car la majorité des applications tournent en php4. Cela engendre assez peu de demandes d'utilisateurs.

A noter une expérience assez pertinente : la prochaine version du moteur de blog dotclear nécessite le support de php5 pour fonctionner. Hasard ou non, un certain nombre d'utilisateurs ont de ce fait demandé à leur hébergeur préféré le support de php5 (et accessoirement de iconv et mbstring, ainsi que de mysql>4.1), et certains ont réagi positivement. Par exemple, ovh et free ont emboîté le pas.

Comme quoi, parfois il ne faut pas grand chose pour faire avancer la situation ...

Vous croyez que les access.log de leurs serveurs sont bien sécurisés ?

D'un autre coté, le champagne italien rebouché de 2000, il fallait bien l'ouvrir un jour ou l'autre, à mon avis il se conserve bien moins facilement ...

Faut dire qu'ils l'ont bien préparé, aussi : http://video.google.com/videoplay?docid=7306336142511364044

... à cause de toi, le propriétaire de linuxfr.org pourrait se faire attaquer en justice, vu que justement, tu viens de faire un lien vers chez eux dans ton journal ...

DRM par ci, DRM par là ... tout le monde parle de DRM, mais personne ne détaille ce que c'est.

Litéralement, on comprend "Gestion numérique des droits". Donc, en clair, si je fais un chmod 700 sur un fichier, ou si je protège un répertoire de mon serveur web via un .htaccess et un .htpasswd, j'ai en quelque sorte mis en place un DRM, non ?

En gros, mettre en place des DRMs, c'est à la portée de tout le monde, à partir du moment où les textes ne fixent pas un niveau de sécurité. Du coup, c'est très con de mettre ça dans un texte, sans plus d'informations.

Evidemment, dans les yeux de beaucoup de monde, c'est l'artillerie lourde de Microsoft, Apple & Cie qui essayent tant bien que mal de protéger le contenu de la musique jusqu'à nos oreilles (et plutôt mal d'ailleurs, en témoignent les contournements qui arrivent de partout), mais rien ne dit clairement en quoi devront consister les DRM.

A ce moment, autant ne pas s'embêter, et ne rien demander du tout à l'utilisateur...

Une solution encore plus simple : tu génères un champ hidden aléatoirement (et éventuellement signé, pour éviter qu'il ne soit pré-rempli par un bot) à l'affichage du formulaire, et lorsque l'utilisateur clique sur submit, un trigger javascript transforme le champ en question via un algo quelconque (un hash, un rot13, ...). Il suffit alors de recalculer ce code coté serveur et de vérifier qu'il est bien conforme.