gabuzo a écrit 236 commentaires

Au dela de la syntaxe le gros avantage d'ipf et de pf sur les systèmes de filtrage sous Linux que je connais (ipfw et ipchains je ne connais pas iptable) est qu'il est possible de charger l'ensemble des règles en une seule commande.

C'est intéressant comme technique mais outre le faire que la société trouvée par le whois ne correspond pas nécessairement à la société à laquelle appartient la machine (par exemple pour toutes les machines des particuliers chez noos on risque de retomber sur noos) tu négliges que :

• l'attaque est le fait d'un vers et donc n'est probablement pas lancée de manière consciente par l'utilisateur de la machine ;


• si c'est un serveur personne ne sera là pour regarder le popup ;-).

Cependant c'est peut être une technique à creuser pour prévenir les admin des machines infectées.

Pour cette attaque je fais un bête :

grep -F 'c+dir' /var/log/httpd/access_log
Et je trouve 951 lignes depuis 15h37 aujourd'hui contenant des trucs comme :

"GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0"


Après il est assez difficile de réagir. J'avais trouvé quelque part un script qui à partir des logs d'apache ajoutait des règles de filtrage des paquets IP pour interdire ceux en provenance des machines d'où provenaient les attaques. Je suis assez peu sûr de l'efficacité du truc car je ne pense pas qu'une machine infectée revienne souvent scanner la même IP.

Il fut une époque où des clones de macs étaient légion, qu'en est il ? qq1 connait des constructeurs de bécanes PPC standard ? Ca ferait une belle workstation, ça....

Effectivement il fut un temps où les clones Mac était légion. C'était l'époque où l'on pensait pouvoir porter AmigaOS sur ces plateformes PPC.

C'était aussi l'époque où Apple avait décidé d'autoriser le clonage des Macs comme l'avait fait à son époque IBM.

Entre temps Steve Jobs est revenu et, pour des raisons plus ou moins justifiées, a décidé de revenir sur cette politique. Du coup les fabricants de machines PPC on été obligé d'arrêter les frais puisque marché pour des machines PPC non mac était proche de 0.

« Je viens d'entendre que des avions de la chasse américaine aurait décollé mardi matin mais n'aurait pas eu le temps d'atteindre les avions. »

De toute façon je pense que la chasse n'aurait pas pu faire grand chose contre le premier avion. Comme l'a fait remarqué quelqu'un dans cette discussion il aurait été difficile en l'absence de preuve de l'attentat de justifier la mort des civils se trouvant à l'intérieur des avions et des civils qui se seraient trouvé dessous (la zone Boston New-York est très urbanisée).

Comprends pas bien, la: Nessus est sous GPL, ils ont pas obligation de préciser le soft qu'ils utilisent si c'est fait publiquement ?

Non je ne pense pas. Ceci dit rien n'empêche Renaud d'ajouter une clause pour ça mais ne pas oublier que cela voudrait dire aussi qu'il obligerait l'auteur d'une merde infâme à mentionner basé sur Nesus ce qui ne serait pas nécessairement une bonne publicité.

J'ai l'impression que c'est un problème qui a été étudié dans les licenses BSD et qui finalement n'a pas été vraiment tranché. De mémoire il existe plusieurs variantes de la licence BSD. Une première indiquant qu'il est nécessaire de mentionner le nom du produit et une seconde l'interdisant au contraire. Les deux ont leurs avantages et leurs inconvénients.

Dans le cas de nessus est-ce que tu ne pourrais pas ajouter un clause couvrant l'utilisation de Nessus pour la création de services qui indiquerait, comme dans le cas d'une des licences BSD qu'il est nécessaire de mentionner l'utilisation de Nessus ?

Je ne me rappelle plus de toute l'histoire mais il me semble qu'à l'époque de son arrestation certains avaient trouvé que Mafia Boy était un suspect bien pratique et doutaient qu'il ait été capable de faire ce dont il était accusé. Quelqu'un pourrai nous rafraîchir la mémoire ?

Autre sujet: avant il n'y avait pas de limite du tout. 3 cons s'accaparaient 80% de la bande passante de Noos avec des serveurs FTP. Le compteur est entré en vigueur a ce moment la, pas forcement "pour faire du fric", mais plutot parce-qu'il y aura toujours des gens qui ABUSENT.

Mouais je dubite beaucoup sur les trois personnes qui accaparent 80% de la bande passante. Même avant le compteur et avant le compteur chez Noos il y a avait une limitation en download de 2Mb/s. Si cette affirmation est vraie (3 personnes qui accaparent 80% de la BP) cela voudrait dire que Noos disposait de 7,5Mb/s de bande passante. C'est un poil limite non ? (Le raisonnement est le même dans le sens upload). Je pense donc que c'est plus un argument de Noos pour justifier la mise en place des limitations (en particulier la limitation à 512Kb/s en download) qu'autre chose.

Pour en revenir à la news, le principe évoqué sur Yahoo est très différent du compteur de Noos puisqu'il ne s'agit pas de mesurer la consommation de quelqu'un mais de pouvoir facturer l'accès à certains services.

Sans être pessimiste, avoir un format techniquement parfait ne sert à rien dans la pratique : il faut des contenus. Or pour l'instant le fournisseur principal de contenus vidéo s'appelle Hollywood et jamais Hollywood n'a utilisé de format libre depuis plus d'un siècle que l'industrie cinématographique existe (le MPEG2 est protégé par des brevets, le 35mm à sa sortie aussi). La seule exception à ma connaissance est l'adoption par la Fox du CinemaScope en 1953 et encore cela s'explique par un certain nombre de circonstances exceptionnelles.

Tu confonds un peu les choses. Il y a au moins trois choses impliquées dans une vidéo : le transport (Quicktime, Avi, Mpeg), le codec audio (MP2, MP3, WMA) et le codec vidéo.

Si les specs du transport quicktime sont publiques ce n'est pas le cas des codecs. Par exemple xanim distribue la plupart des codecs uniquement sous forme de bibliothèques compilées et assorties de licences restrictives (pour Cinepak il est interdit d'utiliser le codec autre part que dans Xanim). C'est uniquement au prix de ces restrictions (et de la signature d'un NDA) que l'auteur d'Xanim a peut obtenir les specs nécessaire à l'élaboration des codecs sous Linux.

Le problème est que la quasi totalité des vidéo QT utilisent maintenant le codec de Sorenson. Or Apple a conclu un accord d'exclusivité avec Sorenson. Il n'est donc possible d'obtenir les specs du codec qu'après l'accord d'Apple ce que Apple a refusé jusqu'à présent.

Le but poursuivi par Apple est simple : s'imposer sur le marché de la vidéo en ligne (les contenus) en empêchant ses concurrents (Microsoft en fait) de fournir des outils permettant de lire les vidéos QT avec ce nouveau codec.

Il est donc impossible même muni de la meilleure volonté du monde de faire un lecteur quicktime fonctionnel sous Linux.

Ce n'est pas faux. En revanche ce qui me choque un peu c'est que Dolby a réussi à faire adopter le standard AC3 comme une norme au niveau des flux MPEG (pour mémoire il est obligatoire dans la "norme" DVD d'avoir soit une piste AC3, soit une piste PCM) et que de ce fait le système a été publié. Sachant que ac3dec est une implémentation basée sur la norme ne reprennant pas a a priori de code développé par Dolby.

Version courte : Oui !

Version longue : non bien sûr pour peu que le métier de la boîte soit lié au développement de logiciel c'est peut probable. Mais dans la pratique savoir que M. Tartempion a un compilateur C sur sa machine ne t'arrange pas des masses car il est sur un autre site ; ne travaille pas du tout sur la même chose que toi et malgré toute sa bonne volonté acceptera difficilement que tu le virer de son poste une journée pour faire tes trucs. Donc ça revient au même.

Bah vous achetez une licence pour un compilo C

Bah oui mais non. Lorsqu'une boite commence à avoir une certaine taille tu peux difficilement acheter un logiciel comme un compilateur C en claquant des doigts. Ce n'est pas nécessairement impossible mais ça prend du temps.

La plupart des engines vont te donner : L'exception et le message associé, la stack trace complète, le numéro de la ligne DU JSP ou l'erreur s'est produite, ...

Je veux bien le nom des moteurs car avec Tomcat 3.2.1 j'ai le numéro de ligne de la servlet, rien de plus.

Effectivement cela se passe ainsi : lors d'une requete vers un JSP, l'engine regarde si le JSP a deja été compilé. Si oui, il l'execute, si non, il génère le servlet, le compile, puis l'exécute. Une fois que le JSP a été compilé, il ne devra plus l'etre. De plus, tout ça est 100% transparant pour le développeur.

Oui c'est assez vrai sauf dans un cas particulier. Sur un filesystem qui ne fait pas la différence en tre majuscules et minuscules (NTFS pour ne pas le nommer) on peut s'amuser à appeler d'abord http://azerty/qwerty.jsp(...) puis http://azerty/QwErTy.jsp.(...) Avec Tomcat on se retrouve avec une erreur 500 pour ClassNotFoundException. C'est con mais Tomcat recherche le fichier QwErTy.class, le trouve car le FS ne fait pas la différence avec qwerty.class. Lorsqu'il essaye d'instancier la classe QwErTy et bien il n'y arrive pas puisque la classe dans le fichier est "qwerty" :-(.

Java est justement réputé pour s'interfacer avec un peu tout et n'importe quoi sans trop de problèmes ... Et ça se vérifie dans la pratique ! J'ai récemment du faire l'interfacage entre des bibliothèques C++ d'un logiciel de mathématique et du code Java, ça s'est passé sans problèmes !! J'ai du compiler du C ? Et alors ? Je ne vois pas le problème :-)

Bah moi j'en vois un. Lorsque tu es dans une entreprise et que tu n'as pas de licence d'un compilateur C (non gcc ça ne va pas car sous Windows gcc produit du code "cygwin" donc dépendant de l'environnement du même nom). Bref rien de techniquement infaisable mais dans la pratique impossible à faire. Sinon il faut noter que dans un service d'une entreprise travaillant uniquement en Java trouver quelqu'un pour faire le stub en C peut être un problème.

Aucuns des Servlet engine que j'ai utilisé n'ont encore planté ainsi ;-)

Bon faut que tu me donnes l'adresse de ton fournisseur de morteur de serlvet, moi j'en ai une par semaine. :-)

(PS : si tu as des URL de site "comment bien faire ses applications JSP/Servlet" je prend).

Désolé, moi y'en a pas être d'accord. Il ne faut pas nécessairement un serveur d'application pour faire du JSP/Servlet mais uniquement un moteur de servlet (comme Tomcat par exemple). Un serveur d'application tel que Weblogic, Borland AppServer ou Websphere ajoute au JSP/Serlvet les EJB et autres J2EEseuries.

Concernant l'article lui même :

- Comme cela a été dis, le debuggage des JSP est une catastrophe (Internal server error avec un numéro de ligne qui ne correspond pas à qq chose dans la page JSP) ;

- Le principe de fonctionnement des JSP est un millefeuilles : les jsp sont traduits en servlet (une classe java qui enverra sur "stdout" ce qui doit être envoyé au navigateur), le code java de cette servlet est alors compilé en bytecode java qui va être chargé par le moteur de servlet et exécuté.

- « ce qui fait la force de JSP, ce n'est pas JSP lui même, mais c'est JAVA », j'ajouterais que c'est aussi sa faiblesse on notera en particulier la difficulté pour s'interfacer avec des bibliothèques "natives" (c'est possible mais il faut un compilateur C pour faire le stub) ; la lourdeur du JRE (trois ou quatre objets un instancier pour lire un fichier ligne à ligne) et ses manques (impossible de locker un fichier en pure java) ;

- concernant l'interfaçage, PHP est nettement plus souple puisqu'écrit en C on notera que PHP s'interface avec COM sous Windows ou même Java ;

- dans la version "out of process" de JSP/Servlet on notera qu'un plantage du moteur de Servlets (core ou Docteur Watson) bloque tout le site alors qu'un plantage identique en PHP ne bloquera que la requête en cours.

Mis à part ces "oublis" l'article est intéressant.

De toute façon mod_perl rewlz ;-).

On peut aussi ajouter que le protocole expérimental n'est pas expliqué. En particulier est-ce que les écoutes se sont faites en aveugle ou est-ce que l'on a dit à l'auditeur voici un extrait WMA ? Est-ce que le test comportait des extraits destinés à tester la "fiabilité" des auditeurs (par exemple en faisant écouter le même extrait deux fois pour comparer les appréciations).

Enfin côté MP3 il manque le nom de l'encodeur utilisé ce qui est très très important sachant qu'un mauvais encodeur même à 320kps ne donne pas de bons résultats.

Si ça c'est pas un troll, je ne m'y connait pas.

Impossible car la licence d'IPF n'a jamais donné le droit de redistribuer une version modifiée du code.

Bon je ne veux pas juger cet article que je n'ai pas encore lu ni "troller" mais bon Motif pour les utilisateurs et les clients je dis bof.

À mon avis le premier commercial qui propose un produit avec un look "motif" à un client se fait soit jeter à coup de pieds au cul soit rire au nez.

Tiens plutôt que de disserter sur un possible navet Oh! Lit Woodien voici un extrait de l'article de la BBC sur ce soit disant piratage qui fait assez peur :

But Europe, like the US, is making attempts to stop piracy. Lavinia Carey, director of the Alliance Against Counterfeiting and Piracy, said the EU copyright directive was soon expected to outlaw or place restrictions on the manufacture and sale of technology that could be used to crack encryption systems that protected DVDs and CDs.

Alors à quand la version européenne du DMCA ?

Je ne veux pas (trop) troller mais dès le début il était clair que la participation au concours s'accompagnait d'une clause de non divulgation des méthodes utilisées. Il était donc de notoriété publique que dès le départ de "concours" était un piège à con destiné à faire travailler les universitaires à l'oeil. D'ailleurs si je me souviens bien, lors de l'annonce de ce concours, l'EFF avait appelé à le boycotté à cause justement des clauses de non divulgation.

Le seul point "positif" de cette affaire est finalement de montrer combien le DMCA peut être liberticide et appeler à la vigilence pour éviter que de telles lois soit votées dans le reste du monde. Pour les USA j'ai malheureusement peur qu'avec le larbin que les industriels ont mis à la maison blanche il y a ait peut d'espoir que le DMCA soit amendé ...

Attention c'est une très mauvaise idée de recompressée du MP3 en Ogg. Le résultat sera au mieux au niveau du MP3 d'origine et probablement nettement moins bon.

J'ai installé les drivers et j'ai fais quelques tests avec ma HP640c.

Le premier test pour me mettre en forme était de comparer le driver PCL de ghostscript avec celui de HP. Pas d'hésitation sur le résultat, le driver HP est nettement meilleur que le driver PCL qui ne donne que des couleurs très approximatives et nettement trop foncées.

Le deuxième test consistait à imprimer une même photo sur papier ordinaire avec gimp-print et le driver HP600 series et une autre avec le driver HP en passant par une sauvegarde postscript de l'image. Je suis passé par la sauvegarde au format PS plutôt qu'une impression sur une imprimante PS car dans ce cas gimp-print effectue malgré tout des corrections qui font doublon avec ce que fait le driver HP. Là encore le driver HP est meilleur mais ce n'est que d'un poil (voire deux).

Dernier test enfin, comparer une sortie d'une même photo avec gimp sous windows (et les drivers HP sous windows donc) et la même photo avec les drivers HP sous Linux. Last but not least, j'ai fait cette impression non pas sur papier ordinaire mais sur du papier "photo" mat de M. HP (Premium Plus pour les avides de références). Avant de donner le résultat une petite précision sur la plus grosse limitation du driver Linux (de mon imprimante). Sur papier photo, l'imprimante est capable de faire du 600x300 (probablement en double passage). Ze problème est que sous Linux le drivers refuse de faire plus que du 300x300. Le résultat donc était prévisibleme et bien qu'ayant utilisé la même photo et le même papier la sortie sous Windows explose littéralement la sortie sous Linux.

Pour terminer sur les détails gore. Les drivers sont prévus pour GS5.50 mais j'ai réussi à les faire fonctionner avec le GS6.01 que j'avais sans grande difficulté. Attention lors d'une impression il y a génération d'un fichier temporaire qui peut devenir très grand dans /tmp. Sinon pas grand chose d'autre si ce n'est que les RPMs ont été générés par la version 4.x de RPM et donc illisibles par le rpm 3.0x de ma Mandrake.

Un bon début pour HP mais on est assez loin de ce que peut faire l'imprimante. En conclusion j'attend une intégration des drivers HP dans gimp-print pour être heureux.

Je me trompe peut être mais il me semble que contrairement aux autres marques, Epson publie les specifications des ses imprimantes. C'est probablement pour cela que gimp-print les supporte.

L'approche d'HP est effectivement la meilleure (drivers en GPL) mais je préfère largement une société publiant les spécifications de ses produits afin de permettre le développements de drivers sous Linux, *BSD ou autre que des drivers Linux fermé comme NVidia fait pour ses cartes.

En parlant de Canon une news du 24 février (http://linuxfr.org/2001/02/24/2449,0,0,0.php3(...) ) a mentionné le fait que l'on trouvait sur le site japonais de Canon des drivers en GPL pour quelques modèles.