photo of devloop

devloop :: blog

sécurité informatique, programmation, Linux et plus encore

Subscribe to RSS feed

Posts tagged with "opera"

Mise à jour urlfilter.ini français

, , ,

J'ai mis à jour le fichier urlfilter.ini permettant de bloquer les pubs (ads) sous Opera.
Récupérez le ici

Support de proxies SOCKS dans Opera

, ,

Opera a beau avoir tout un tas de fonctionnalités pratiques, il en manquait une depuis des années : le support des proxies SOCKS.

C'est maintenant réglé avec les récentes builds.

Accèder à GMail depuis Opera

, ,

Depuis quelques jours, le chargement de GMail dans le navigateur Opera n'aboutit pas : on reste bloqué à 95%.

La raison est dûe à Google qui a fait quelques modifications sur l'interface de son webmail.
En attendant qu'une nouvelle version d'Opera vienne corriger ce souci de compatibilité (ou que Google daigne bien s'en occuper), une astuce a été proposée sur les forums d'Opera que je reprends ici en français.

Il vous faut d'abord créer un dossier où seront placer vos userjs (il n'y en a pas par défaut).
Personnellement j'ai créer un dossier userjs dans mon dossier personnel Opera (où sont stockées les préférences etc)
Dans ce nouveau dossier, créer un fichier gmailfix.js dont le contenu est le suivant :

// ==UserScript==
// @name hide faulty bind implementation
// @include *://mail.google.*
// ==/UserScript==

delete Function.prototype.bind;

Ce Javascript sera utilisé par le navigateur à chaque fois que Opera ira sur GMail.
Mais pour valider ça il faut d'abord dire à Opera quel est le chemin vers le dossier des userjs :
Opera > Réglages > Préférences > Contenu > Options Javascript puis choisir le dossier en bas de fenêtre
et ensuite activer l'utilisation des userjs avec HTTPS :
aller à l'url opera:config, effectuez une recherche sur "Javascript", cocher User JavaScript on HTTPS et enregistrez)

Après ces manipulations, plus de problème pour charger GMail dans Opera up

Je suis passé à openSUSE 11.3

, , , ...

Mon aventure avec openSUSE a commencé avec la SuSE 9.1. J'ai d'ailleurs toujours le DVD de l'époque qui était fourni avec un magazine.
Même si je suis passé à un moment à Ubuntu et Slackware et que j'ai pû tester de nombreuses distributions, je suis toujours revenu à openSUSE qui me satisfait toujours malgré les petits pépins que j'ai pû rencontrer lors de migrations à la version supérieure.

Pour mon passage à la 11.3 j'avais envie de changer un peu. Au lieu de faire un upgrade comme j'en ai fait depuis plusieurs numéros de version déjà, j'ai décidé de reprendre sur des bases propres, c'est à dire supprimer la partition racine contenant les logiciels installés.

En plus de se débarasser ainsi des logiciels/librairies inutiles, c'était l'occasion de finalement faire le saut vers le 64bits puisque Shirley a un proc AMD64 et que j'étais resté sur du 32bits principalement par manque d'information et de peur que trop de logiciels soient indisponibles dans cette architecture.

L'objectif c'était aussi de se débarasser de deux partitions Windows que je n'utilisais plus (un XP et un 2000) d'autant plus que je suis passé de mes 700Mo de rams (oui 700Mo p ) à 2Go.
J'ai donc bon espoir de pouvoir virtualiser certains systèmes d'exploitation autre que Minix, Windows 98 ou MenuetOS bigsmile

L'installation en elle même s'est parfaitement bien déroulée. Graphiquement c'est beau ! A tel point qu'on se demande comment ils font pour nous étonner à chaque fois p
J'ai passé beaucoup de temps à réfléchir à comment j'allais organiser mes partitions puisque je voulais en garder une, virer deux partitions primaires et redimensionner une primaire et une autre logique. Bref un sacré casse tête bomb
J'ai changé certaines partitions de ext2/3 à ext4 au passage.

Ce qui a été plus problématique c'est la personnalisation du système après installation.
Premièrement l'installation du driver graphique nVidia nécessitait d'effectuer une manipulation particulière (décriteici dans la section Warning) : lancer le système avec une option nomodeset, créer une variable dans sysconfig et rebooter, tout ça pour pouvoir décharger le module nouveau et installer le driver proprio à la place bigeyes

Maintenant le driver nVidia est disponible sur un dépôt externe pour ceux qui le souhaitent et l'installation est aisée. De mon côté j'ai toujours récupéré le driver sur le site officiel rolleyes

Premières choses à effectuer ensuite : installer Opera bien sûr, Tor et le pager most dont je ne me séparerais pour rien au monde p
J'ai voulu installer la dernière béta d'Audacious mais malgré une compilation réussie, il segfault à chaque fois que je tente d'ouvrir quelque chose cry
En attendant et en espérant que cela vienne de la version béta, je suis passé à DeaDBeeF pour la lecture de mp3. C'est simple et fonctionnel comme j'aime, mais pas aussi beau que Audacious et surtout ça ne lit pas les CD audios comme il faut. C'est à dire que comme la plupart des softs capables de lire ce type de support ça le fait en faisant un boucan d'enfer (on entend plus le CD tourner que la musique) au lieu de le faire silencieusement.

Cette version d'openSUSE a arrêté de nous casser les pieds avec Pulse et on retrouve ce cher ALSA smile

La distribution est rapide à démarrer, en un clin d'oeil on se retrouve devant l'écran de login.
En revanche je trouve la performance de KDE 4.4 médiocre yuck et ce malgré mes 2Go de ram et le type d'activité que j'ai sur le poste (surf web, lecture de musique et vidéo et programmation) : ça saccade, c'est poussif, ça manque de fluidité. En lançant top on voit que Xorg pompe pas mal. La cohabitation avec KDE 4.4 est difficile.

Je suis donc parti à la chase à la "gaspi" et aux petites astuces en tout genre.
J'ai gagné pas mal en bidouillant mon Xorg.conf, en désactivant le scrolling fluide sous Opera et Firefox (aussi avec cette manip) et c'est déjà bien mieux smile
Je garde encore l'astuce raster en réserve au cas où.

J'ai aussi empéché le redimensionnement des fenêtres sous Firefox car ça commencait à me gonfler knockout

Cela dit... il y aurait plus simple. Il suffirait de se servir de LXDE à la place qui est bien plus léger et que cette version d'openSUSE a très bien intégré.
Pour commencer il n'y a plus à bidouiller soit même la config, le menu & co.
Deuxièmement le mot de passe root est maintenant demandé lors de l'appel aux applications administratives (YaST, Wireshark...)
Enfin, là encore le graphisme est soigné.

Bref malgré les piètres performances du KDE que je cherche toujours à améliorer, je suis globalement satisfait de cette nouvelle version smile
D'ailleurs je vous laisse, j'ai un applet qui m'indique que je dois installer un correctif de sécurité pour gnupg2.

Un screenshot pour la route smile

J'ai testé Opera Unite

, , ,

Comme je suis de près les différentes build de la version d'Opera 10 à venir, je ne pouvais pas échapper au buzz concernant Opera Unite.

J'ai donc mis en service ma page depuis quelques temps déjà et ait eu l'occasion de tester les différents services proposés en standard.

J'ai d'abord rencontré des problèmes pour que la page soit accessible. Bien que l'utilisation de UPnP soit activée dans Opera et sur le routeur, ce dernier ne semblait pas recevoir la moindre demande de port. J'ai donc du NATer moi même le port 8840 pour recevoir les connexions. Il est possible que cela soit corrigé depuis, je n'ai pas réessayé la configuration depuis la première build.

Le Fridge qui permet de laisser des mémos affichés sous la forme de post-it et le Lounge qui est un salon de discussion très sommaire sont plus des gadgets à mes yeux et je les ais désactivé assez tôt. A noter que pour le Loundge je n'ai pas retrouvé dans les dossiers de cache Opera les conversations ce qui est un bon point question vie privée ("privacy"). Bien sûr les données sont transférées en clair sur le réseau et non protégées par SSl/TLS.

Le système de galerie photo et le service faisant office de serveur web sont plutôt sympathiques et permettent à des personnes souhaitant créer un site Internet de le faire facilement et de disposer d'un nom de domaine pour pas un rond smile
Evidemment on se limite à des pages statiques, il n'est pas question de faire exécuter du PHP ou CGI.

Pour le peu que j'ai regardé niveau sécurité, je n'ai rien remarqué de mauvais. Les cookies ne sont pas définis sur un sous-domaine global mais bien le domaine exact pour la "domiciliation" de l'utilisateur (home, work etc) et l'administration se fait par le protocole spécial unite:// (donc pas d'attaques du type CSRF)

J'ai eu plus de difficultés à faire fonctionner le Media Player mais le problème venait en fait de FlashBlock pour Opera qui cassait l'affichage des pages sad
Une fois corrigé, les flux passent bien et on ne sent pas les connexions passer depuis la navigateur (évidemment c'est selon le nombre de personnes connectées).

Quand au système File Sharing, il permet à chacun de mettre très simplement à disposition des fichiers. On regrette bien sûr de ne pas pouvoir spécifier plusieurs dossiers de partage.
Les transferts semblent se faire sans problème. Lors d'un test on a même pû transférer un fichier d'environ 700Mo... en revanche ce transfert utilisait la totalité de la bande passsante en upload sad Opera semble avoir rectifié le coup avec la dernière build en date.

Pour ce qui est des autorisations d'accès, c'est pour le moins simple : ressources publiques, protégées par un mot de passe ou privées (seul vous y accèder).
Un système permettant d'uploader des fichiers vers son ordinateur pourrait aussi être sympathique (transfert de fichier dans les deux sens)

En revanche le système dans sa totalité n'est par parfait et il arrive que l'on doive relancer Opera pour refaire fonctionner les services qui ne répondent plus.
J'aime vraiment la possibilité que le service offre à chacun (même des "non-initiés") de pouvoir mettre en place et gérer soit même un petit espace sur Internet smile

Les navigateurs ont bien du mérite

, , , ...

Ce n'est pas nouveau !
Quand on voit les différents standards (X)HTML, les normes ECMAScript, les histoires d'encodage des caractères, les flux RSS, les images, les animations Flash, le format CSS et que tout ça avance à une vitesse monstre, c'est déjà pas facile.
Mais quand en plus chacun y va de ses "solutions" propriétaires, ses balises à lui, les webmestres qui s'improvisent du code HTML entre deux standards (en supposant que les balises en question soient fermées), l'interprétation du code qui diffère d'un navigateur à un autre et les astuces à ajouter dans les pages pour réparer les erreurs... on s'en sort plus.

On pouvait penser que la base (le protocole HTTP) était, lui, correctement implémenté... mais après avoir travaillé sur une nouvelle implémentation des cookies dans Wapiti, force est de constater qu'on est loin du compte sad

Premier sujet d'énervement : les dates utilisées dans les entêtes. Quand un serveur déclare un cookie auprès du client, il utilise l'entête "Set-Cookie" avec un champ nommé "expires".
Ce champ donne la date à laquelle expira le cookie associé. Or cette date n'est pas une date relative mais une date "absolue" dans ce style : "Sat, 27 Jun 2009 16:33:21 CET".
C'est déjà énervant de devoir jongler avec les fuseaux horaires mais en plus il faut jongler avec le format de la date.

Lors de mes tests j'ai trouvé quatres formats de date différents présents dans le champ expires des cookies ou les entêtes HTTP Date et Expires.
Avec ou sans virgule, avec le décalage horaire sous forme numérique ou sous la forme de trois lettres (GMT, CET), avec ou sans tirets, avec le mois placé avant ou après le numéro du jour.
Parfois un même serveur (comme www.amazon.com) utilise deux formats de date différents, juste histoire de compliquer les choses :|

Le plus drôle c'est que si on jette un coup d'oeil aux RFC 2109 et RFC 2965 qui définissent le bon usage des cookies dans le protocole HTTP, on apprend qu'il faut utiliser un champ baptisé "max-age" pour l'expiration des cookies et que sa valeur est... relative au moment présent !! (par exemple max-age=500 définie une durée de vie de 500 secondes)

Seulement presque aucun serveur, CGI et compagnie ne respectent ces spécifications. Au lieu d'utiliser les méthodes revues et corrigées, ils continuent depuis plus de 10 ans de se baser sur les anciennes specs de Netscape.
La raison serait principalement le non respect de ces specs par le navigateur de Microsoft et il semble que ce dernier persiste même arrivé à la version 7 sad

Malgré l'existence d'un entête "Set-Cookie2" compatible avec l'ancienne méthode de Netscape, les navigateurs ne semblent pas bien pressés de suivre les bonnes règles. Il n'y a qu'Opera qui fait figure de bon élève dans cette histoire sad

La librairie libcookie de Python montre aussi des défaillances. Pour le moment j'ai pu réécrire le script cookie.py, en analysant directement les entêtes et abandonnant le format LWP/Netscape pour un format XML au niveau du stockage smile Vu comment les choses se présentent ça va se terminer sous la forme d'une librairie.
Les modifications ne sont pas encore visibles dans le SVN.

Hors sujet :
Qu'est-ce qui est arrivé en premier ? L'extravagance de Michael Jackson ou sa dépendance aux médicaments et autres substances ?
La réponse en vidéo. How !

Plantages sous Linux

, , , ...

J'ai beau aimer Linux penguin et dire régulièrement du mal de Windows (la gestion des fenêtres est tout simplement exaspérante face à un bon KDE), j'admets tout de même volontier que Linux est aussi sujet à des plantages.
MAIS quand ça survient sous Linux, on se dit qu'il y a une bonne raison et que surtout il y a une façon de trouver quelle en est la cause et d'agir pour que ça ne se reproduise plus. C'est tout l'avantage d'un système open-source face à un système propriétaire où l'on peut juste... subir et espérer que les devs découvrent puis décident finalement de corriger le problème sad

Je ne sais plus exactement depuis combien de temps j'ai ce souci mais ça fait un bail... en fait probablement depuis que j'ai Shirley bigeyes
Le symptôme est toujours le même : tout d'un coup le disque dur se met à gratter et les commandes ne répondent plus. Seul le curseur de la souris est d'accord pour réagir (par intermittence). Si on est suffisamment rapide (c'est rare), on peut parvenir à fermer les applications et éviter le pire.
Le pire (qui est tout de même loin d'être l'enfer mais très énervant) c'est que le système reste inutilisable et gratte pendant un bon moment. Ca peut durer jusqu'à une demi-heure dans mon cas.
Ce comportement est typique d'un programme quelconque qui explose son utilisation mémoire et, une fois la RAM complètement utilisée, s'attaque à la SWAP (d'où l'utilisation intensive du disque dur)

Si on est patient, tout se termine "bien". Le kernel s'est chargé de tuer toutes applications graphiques, le WM et Xorg inclus (bref la crémerie avec la crémière et ses yaourts) et on est bon pour se relogger.
Quelques minutes plus tôt on s'acharnait à faire des Ctrl+Alt+F1 dans l'espoir de pouvoir régler nous même le problème.

Il est très difficile de déterminer quel programme est à l'origine du plantage... surtout quand on a toujours les même programmes ouverts p
Longtemps j'ai soupçonné le "operapluginwrap" qui est le programme qui gère les plugins sous Opera. Son utilisation du CPU grimpe en flèche dès que l'on tombe sur du Flash (d'où l'utilité d'un FlashBlocker pour limiter les dégats).

Au même titre, j'ai soupçonné Vuze (client BitTorrent développé en Java), ce qui m'a poussé à passer à Deluge récemment.
Mais si on suit la logique, le souci pourrait aussi bien être lié à Firefox (souvent ouvert aussi) ou des daemons (mysqld, apache, tor...)

Malgré le passage à Deluge, le souci est réapparu. Je suis donc allé fouiller dans les logs sherlock
La dernière fois j'avais vu des appels à un programme nommé "kwin_killer_helper", sorte de soupape de sécurité de KDE qui tente de fermer des programmes quand ça part en sucettes... seulement son action a l'air peut efficace est surtout l'application n'est pas configurable sad

Cette fois j'ai remarqué des références à "oom-killer". Il agit de la même façon que kwin_killer_helper mais au niveau du noyau.
Le problème c'est qu'il semble reporter seulement le programme qui fait déborder le vase or ce n'est pas forcément celui qui s'est chargé de le remplir à 99%... toutefois en faisant des statistiques, on peut en déduire les programmes qui sont plus gourmants que les autres.

Ainsi un grep sur /var/log/messages me donne 9 "java invoked oom-killer", 1 pour opera, 1 pour policykit-kde et le dernier en date pour klipper eek
Le bon côté c'est qu'en abandonnant Vuze le problème apparait moins souvent mais il reste toujours présent sad

Si je regarde dans les logs plus anciens (archivés par logrotate), on retrouve java mais sont aussi mis en cause hald-addon-stor et mysqld doh

Si on effectue des recherches sur Google, on retrouve tous un tas de programmes variés qui ont "invoqué" oom-killer dont certains sont réputés stables.
Le souci semble donc venir d'ailleurs.

Pour certains, le souci est lié à la taille de la SWAP... il faudrait qu'elle soit au moins de la taille de la RAM. Je ne dirais pas que je n'y crois pas une seconde... mais presque (va pour deux secondes d'incrédulité rolleyes )
Pour d'autres (et sans doute plus fiables) et ici, ce serait lié à l'utilisation d'un système 32bits avec une machine 64bits (ce qui est mon cas).
Je vais probablement suivre la seconde possibilité mais je ne compte pas réinstaller mon système pour le moment (j'attends la version 11.2 d'openSUSE) p

Pour le moment j'ai vu ici que chaque processus a dans /proc/ des fichiers oom_adj et oom_score dont il serait peut-être bon de connaître l'utilité confused
Et enfin un comique a enregistré le domaine oomkill.net sur lequel ont peut lire le boût de kernel correspondant à ce tueur de gaspilleurs de mémoire (oom = "Out Of Memory") ninja

FlashBlock pour Opera

, ,

Mieux vaut tard que jamais, j'ai découvert FlashBlock pour Opera. Je l'utilise depuis une semaine et j'en suis très content.
Il est composé d'un UserJS et d'un feuillet de style. Une fois les fichiers copiés dans leurs dossiers Opera, il suffit d'aller dans Afficher > Style et de sélectionner "Flash Blocker" pour l'activer.
L'utilisation est exactement la même que celle du plugin Firefox et en plus c'est compatible avec les dernières build béta d'Opera 10 smile

FlashBlock pour Opera

Python Opera Cache Dumper

, , , ...

Après le cookie dumper, voici le "cache dumper" qui comme son nom l'indique permet d'analyser le cache du navigateur Opera.

Sous Opera, on trouve deux dossiers de cache.
L'un s'appelle "opcache" et sert uniquement aux sites liés à Opera lui-même comme les requêtes à destination du "sitecheck" (système anti-fishing du navigateur), les requêtes vers DragonFly (API pour développeurs web intégré au navigateur) et requêtes vers les autres sous-domaines d'Opera.
Le second dossier est le dossier "cache4" et conserve la grande majorité des fichiers gardés en mémoire par Opera.

Dans les deux cas, les fichiers mis en cache sont renommés sous la forme oprXXXXX (où "XXXXX" est composé de chiffres et lettres majuscules) et un fichier nommé "dcache4.url" présent dans le même dossier est un index qui garde les informations spécifiques à chacun des fichiers.

Il est important de noter que si vous avez coché "Empty on exit" dans les préférences, Opera n'utilisera pas le fichier d'index mais stockera tout de même des fichiers en cache. Les associations entre les fichiers présents dans le cache et les sites Internet correspondants sont alors impossible à déterminer (Opera garde ces associations en mémoire mais ne les écrit pas sur le disque).

Comme pour l'analyse du fichier cookies4.dat la dernière fois, j'ai rencontré certains tags non documentés dans la documentation officielle.
On peut par exemple trouver le tag 0x00 dont la valeur est toujours la même (0x8000000B) et qui ne semble pas avoir de signification confused
Il y a un tag 0x2e qui représente la langue utilisée pour un fichier de cache donné (par exemple "fr_FR").
Tout aussi énigmatique, le tag 0x3a qui me semble lié à l'entête HTTP "Age" reçu comme réponse des serveurs. Un entête qui m'était inconnu et qui m'a fait penser au ver Conficker qui se base sur un autre entête HTTP pour déterminer la date et l'heure actuelle. Le header "Age" semble renvoyer une valeur numérique dans une intervalle prédéfinie et augmente avec le temps... ça pourrait être pratique comme moyen de trouver un nombre aléatoire idea

Enfin on trouve des tags qui permettent au navigateur d'intégrer directement des entêtes HTTP et leurs valeurs dans l'index de cache. Le tag racine est le 0x3b, suivi par le 0x3c. Le 0x3d défini le nom de l'entête et le tag 0x3e sa valeur.

Le programme que j'ai fait prend comme argument le chemin vers le fichier dcache4.url ainsi qu'un dossier où sera placé l'analyse du cache. Si ce dernier dossier n'existe pas, il est créé automatiquement.
Pour chaque fichier référencé dans le cache, le programme détermine sa nature à partir de sa valeur "mime" (image/png, text/html, application/x-javascript, etc) et s'il est compressé ("Content-Encoding" défini par le tag 0x20). Si c'est le cas, le fichier est décompressé (si possible car certains fichiers sont compressés en deflate et non par gzip worried ) avant d'être copiée dans le dossier de destination.
Le programme génère ensuite un fichier HTML qui permet d'afficher facilement l'ensemble des fichiers du cache et leurs métadonnées associées. S'il s'agit d'une image, elle est affichée. Sinon un lien permet d'accèder à la ressource. Les javascripts et codes html ont l'extension txt pour éviter qu'ils soient interprétés.

Comme les descriptions et les images sont chargées dans la même page HTML, ça peut prendre du temps à charger en fonction du cache analysé (il faut mieux un système avec une bonne mémoire p )
Le résultat ressemble à ça (extrait) :

Le code est ici : opcadump.py penguin

Python Opera Cookie Dumper

, , , ...

Je me suis intéressé au format de fichier utilisé par le navigateur Opera.
Bien que les spécifications soient disponibles, on trouve peu d'outils pour gérer les historiques, caches et cookies du navigateur worried
Finalement je suis parvenu à écrire un script Python qui extrait les données du fichier cookies4.dat et les affiche dans un format texte plus conpréhensible que le format binaire d'Opera.
La sortie générée ressemble à ça :
Opera Cookie Dumper
File version: 1.0
Application version: 2.1
Cookie file
Size of idtags: 1 bytes
Size of payload length fields: 2 bytes
MSB: 0x80
===================================
dsource.org
        dsource-auth_data  = a%3A11%3A%22autologinid%22%3Bs%3A6%3A%22userid%22%3Bi%3A-1%7D
        path = /projects
        path = /dsss
        trac_session  = e7f77d380bc7290b2347490c
        path = /tutorials
        trac_session  = 49ca56cec7f142d58d2201ea
userfriendly.org
        __qca  = 1239814048-45958653-24014683
...

Toutes les informations n'apparaissent pas. Actuellement il n'est affiché que le domaine, le path sur le serveur et les noms et valeurs des cookies.

Durant mes recherches j'ai découvert un tag non documenté (tag id 0x26) qui correspond en réalité au champ "Delete new cookies when exiting Opera is checked" dans les préférences de site. Si la valeur est à 2 cela signifie que la suppression est activée. Si la valeur est à 1 ou si le tag est omis cela signifie que la suppression n'a pas lieu.
Il y a aussi un flag 0x27|MSB que j'ai rencontré mais je n'ai pas pû découvrir sa signification confused

Dans tous les cas ça peut être utile pour faire du Web Browser Forensics et le code est disponible ici :
opcodump.py penguin