Planet Libre

Voilà un micro projet qui risque de bien arranger les choses entre les deux mondes : un plugin QtStyle qui utilise (et non pas émule) le moteur de rendu GTK2. Le résultat étant des applications QTistes visuellement (mais pas ergonomiquement) identiques à leurs sœurs GTKistes.

QGtKStyle est donc l'équivalent du célèbre GTK-QT qui fait la même chose, mais dans l'autre sens. La même chose mais avec un peu plus de bonheur semblerait-il si l'on se base pour en juger sur les copies d'écran fournies par l'auteur.

Ceci dit, faut pas s'emballer, ce n'est pas encore tout de suite, pour moi en tout cas, que VirtualBox ou Vym vont ressembler à cela. Car pour l'instant je n'ai juste pas réussi à le compiler. En effet ce code est seulement compatible avec la version 4 de Qt, et même avec la version 4.4 pour être exact, ce qui semble être la cause de mon blocage avec Mandriva qui n'a pour l'instant que la 4.3 en réserve.

Encore un peu d'attente donc pour voir si le projet continue à vivre (car ce n'est pas toujours le cas chez trolltech). En tout cas, l'idée est suffisamment bonne et le rendu suffisamment prometteur pour être relevé.

Une nouvelle version, de nouvelles fonctionnalités, rien de bien extraordinaire me direz-vous. Et pourtant, Flash Player 10 représente un tournant tant pour Adobe que pour la communauté du libre.

En effet, à l'heure où les plateforme de Applications Internet Riche (RIA) se multiplient comme des petits pains (PRISM, AIR, SilverLight, JavaFX, etc.), Adobe s'est donné les moyens de rendre son lecteur le plus universel possible. C'est du coup la première fois qu'un version du lecteur sort en même temps pour MacOS, Windows ET Linux. Ce fait en lui-même est un événement qui prouve que la plateforme libre devient de moins en moins contournable.

Autre aspect majeur, cette version 10 est en réalité la première d'une nouvelle génération suivant les spécification de l'Open Screen Project.

Ce projet vise à définir une plateforme ouverte d'Application Internet Riche basée sur les formats d'Adobe. Il est soutenu entre autre par Motorola, Intel, LG Electronics et peut être résumé par les points suivants :

• Ouverture des spécifications pour les formats SWF et FLV
• Levée des restrictions d'usage sur ces formats
• Ouverture des protocoles Apple Flash Cast et AMF
• Suppression des coûts de licence associé au lecteur Flash et AIR.

Il n'y a donc pas à ma connaissance d'ouverture des sources des lecteur eux-mêmes mais malgré cela, cette initiative devrait rapidement être profitable à gnash , le lecteur libre, qui pour l'heure est d'une stabilité plus que moyenne.

Il ne reste maintenant plus qu'à tester ce nouveau lecteur qui au delà de ce qui vient d'être dit, affiche tout de même une liste impressionnante de nouveautés.

Alors que je mettais à jour mon miroir des différents dépôts Mandriva 2008.1, je découvre qu'est apparu dans main.backports la nouvelle mouture de VirtualBox (1.6).

Tout content, je commence simplement par mettre à jour (urpmi --auto-update) et je lance VirtualBox. Et là... patatra... Déjà, l'outil me prévient qu'il compte convertir ma VM pour la nouvelle version, candide, j'accepte. Ensuite, il s'arrête brutalement me déclarant que mes drivers ne sont pas à la bonne version.

Je vérifie par un petit coup de modinfo vboxdrv et en effet, c'est encore une 1.5.6. Je fais un rpm -qa | grep box, et là, j'ai un joli mix de 1.5.6 et de 1.6. Je décide de désinstaller l'ensemble par un sauvage urpme $(rpm -qa | grep box) (faite gaffe, il se trouve que je n'ai pas d'autre paquets qui contiennent le mot box). Et je relance une installation (urpmi virtualbox). Et là je m'aperçoit que c'est le paquet dkms-virtualbox qui coince, il m'insulte en disant que mon /lib/modules/blabla/build ne contient pas le bon kernel, ou quelque chose d'approchant.

Du coup, je me fâche, et je vire le paquet de source, dkms, dkms-virtualbox et virtualbox. Je vérifie qu'il ne reste rien dans /usr/src et je lance urpmi kernel-source-latest dkms dkms-virtualbox. Et miracle, ça passe cette fois. Sûrement un problème de ménage dans l'arborescence dkms. Bref, je vérifie par un modinfo vboxdrv que cette fois j'ai bien la bonne version du pilote et satisfait, je lance un urpmi virtualbox pour relancer enfin ma vm.

Et là, recoinçage, cette fois VirtualBox me dit que je n'ai aucun droit pour utiliser le driver (qui cette fois est le bon).

Là, je me dis que c'est dkms qui a monté le module en mémoire. Peut être que si je redémarre le service, le script /etc/init.d/virtualbox va magouiller deux trois choses en plus qui permette à un utilisateur standard de touche au module. Je lance donc un service virtualbox restart. Content de mes deux [OK], je relance une dernière fois ma VM, et là, miracle.. ça marche...

Je vais donc pouvoir utiliser cette nouvelle version de VirtualBox en me demandant comment un nouvel entrant, ex-windowsien, peut vivre ce genre d'aventure...

Protéger ses données exposées sur le WEB n'est pas toujours évident et comporte quelques pièges qui donnent une illusion de sécurité alors qu'il n'en est rien. Ce tutoriel ne va pas, loin de là, couvrir tous les aspects du sujet, mais juste tenter d'apporter quelques bases permettant de se protéger à travers quelques cas pratiques.

.htaccess vs configuration

Pour tout ce qui suit, ou presque, existe deux méthodes de paramétrages. La plus simple consiste à placer dans le dossier web à protéger un fichier .htaccess qui contiendra une configuration spécifique à ce dossier. Le contenu d'un tel dossier pourrait être :

Cette méthode a le mérite de la simplicité et protège autant le dossier lui-même que les sous-dossiers qu'il contient, sauf si un autre fichier .htaccess y contrevient.

L'autre méthode, sûrement plus pérenne, est de modifier directement un des fichiers de configuration Apache. Ces derniers se trouvent généralement en /etc/httpd et vous pouvez soit modifier /etc/httpd/httpd.conf, soit créer votre propre fichier .conf dans le dossier /etc/httpd/conf.d. A notez que les localisations peuvent changer d'une distribution à l'autre. Dans tous les cas la syntaxe est à peu près la même que pour un .htaccess:

La seule différence ici est donc la balise Directory qui encadre le code qui aurait été dans un fichier .htaccess et qui indique le chemin absolu à protéger, comme la position d'un .htacess l'aurait fait. Une autre différence cependant tient à la manière dont apache gère les deux types de fichier. En effet, un .htaccess est affectif tout de suite, dés que le fichier est créé et contient les données. En revanche un fichier de configuration nécessite le redémarrage du serveur Apache par un redémarrage du serveur apache.

Maintenant le choix .htaccess ou fichier de configuration vous appartient. Tout ce qui suit devrait fonctionner dans les deux cas.

Fichier de mots de passe

Si nous voulons qu'Apache protège notre dossier, il nous faut lui fournir une liste d'utilisateurs, voire de groupes d'utilisateurs. C'est ce que fait le code suivant en créant d'abord un répertoire et en changeant ses droits, puis en ajoutant avec la commande Apache htpasswd le premier utilisateur (le chemin du dossier et le nom du fichier n'ont aucune importance) :

Pour l'ajout des utilisateurs suivants, le fichier étant déjà créé, le paramètre -c n'est plus nécessaire :

Un utilisateur préalablement créé, pourra être retiré de la manière suivante :

Maintenant si nous vidons le contenu du fichier /var/secured/passwords, nous aurons ceci :

Nous avons donc maintenant les utilisateurs, leur mot de passe, il ne nous reste plus qu'à définir des groupes, même si c'est optionnel. Si nous voulons indiquer que l'utilisateur gaston appartient au groupe webmasters il suffit de créer un second fichier /var/secured/groups contenant les données suivantes :

La syntaxe est ici simple à comprendre. AuthName est le message qui sera affiché dans la boite de dialogue de saisie de l'identifiant et du mot de passe. Gardez cela en tête pour ne pas y mettre de chose trop explicites comme "Bienvenue dans le site contenant tous mes numéros de carte bleue" .

Le second paramètre, AuthType indique à Apache d'utiliser le protocole Basic pour authentifier l'utilisateur. Comme son nom le laisse présager, ce protocole est le plus simple, le plus compatibles avec tous les navigateurs, mais aussi le moins sécurisé comme nous le verrons un peu plus loin. D'autres type d'authentification existent sous Apache par l'intermédiaire de modules spécifiques, comme nous allons le voire aussi plus loin.

Ensuite nous avons AuthUserFile qui indique le chemin vers le fichier que nous avons créé dans le chapitre précédent, et contenant donc nos utilisateurs et leurs mots de passe.

Enfin, la règle d'authentification à proprement parler, require valid-user. Elle indique à Apache que tout utilisateur ayant réussi à rentrer son mot de passe est autorisé à rentrer dans le dossier. Si nous voulions spécifiquement autoriser Robert à rentrer, nous aurions mis require user robert, et pour Gaston et Martine, cela aurais été require user gaston martine.

Vu que nous avons créé un fichier de groupes d'utilisateur au chapitre précédent, autant en profiter. Et si voulions n'autoriser que le groupe webmaster à rentrer, nous aurions cette fois un fichier .htaccess comme ceci :

Plus complet, les deux chemins vers les deux fichiers mots de passe et groupes sont indiqués (apparition du mot clef AuthGroupFile).

Enfin il est possible de panacher tout cela avec des choses du genre : require user robert, group webmaster. Ceci indique à apache que seuls les membres du groupe webmaster sont autorisés, à l'exception de robert.

Utiliser un serveur LDAP

Comme je le disais plus haut, il y a de nombreux modules liés à l'authentification disponibles pour Apache sous la forme de modules. Par exemple si vous vouliez utiliser un protocole Digest au lien du simple Basic, vous utiliseriez le module mod_auth_digest.

De même différent modules permettent de vérifier les utilisateurs, groupes et mots de passe sur une base de donnée plutôt qu'un fichier texte, ou encore un serveur ldap par le biais du module mod_authnz_ldap. Il dépends du module Apache d'accès à LDAP, mod_ldap qu'il faut aussi installer. Ce module permet une authentification Basic adossée à un base LDAP. Un bloc de configuration pour un tel système se présente comme cela

Comme vous le voyez l'esprit est à peu prés le même que précédemment. La ligne AuthBasicProvider indique à apache de se baser sur un serveur LDAP plutôt qu'un fichier. Les coordonnées du serveur apparaissent avec la ligne AuthLDAPURL qui indique le nom de la machine, le port en écoute, ainsi que le domaine pris en charge.

Les deux attributs suivant permettent au module apache de se repérer dans les enregistrements LDAP et d'y trouver les utilisateurs. Le paramétrage que j'utilise ici se base sur la disposition standard d'une base LDAP sous Unix et est à adapter pour un ActiveDirectory sous Windows, par exemple.

Enfin la dernière ligne indique à apache de n'autoriser à rentrer que le group ldap spécifié (ici webmasters). L'utilisateur de ldap-user (ex. Require ldap-user Gaston) permettrait de n'autoriser qu'un utilisateur spécifique. Et ici aussi, le panachage est autorisé en séparant les éléments par des virgules.

A ce stade, nous avons déjà pas mal d'outils pour protéger nos données mais si nous nous arrêtions à cela, cela ne servirait à rien... En effet, ce type de sécurité est aussi valable qu'une porte blindée sur des murs en cartons. Car le gros inconvénient du mode basic est que les mots de passes circulent en clair. Protéger par mot de passe un dossier accessible avec le protocole HTTP est donc très dangereux. Une simple écoute active (mode Promisc) du réseau, si par exemple vous utilisez cela de votre bureau, dévoile aussi sûrement vos secrets que si vous les aviez envoyé à tout le monde par courriel. Pour parfaire notre protection il est donc obligatoire de mettre en œuvre le protocole HTTPS, ce que j'aborderais dans un autre article.

Empêcher le téléchargement des images à partir d'un autre site

Un problème classique est de se retrouver avec une bande passante "volée" parce qu'un Malotru a eu l'indélicatesse de mettre vos images en référence directe sur son site. Ici, pas question de mettre un mot de passe qui bloquerait les utilisateurs légitimes. Les techniques précédentes sont donc inutiles. A la place nous allons utiliser les variables dont nous disposons au sein d'Apache et particulièrement du Referer.

Pour ceux qui ne le savent pas, un navigateur WEB a pour obligation de transmettre au serveur l'adresse WEB de la page qui contient le lien qui a permis d'arriver sur notre site. Cette indiscrétion est déjà bien connu et c'est elle qui permet de savoir d'où viennent nos visiteurs. Cette adresse est le fameux Referer.

Ce qui est un peu moins connu c'est que chaque élément lié à une page de notre site (ex. une image ou une feuille de style), est demandée au serveur distant avec lui aussi un Referer. Sauf que cette fois, c'est l'adresse de notre propre site qui est passé par le navigateur, ce qui est somme toute très logique.

En d'autres termes, toute demande d'image n'ayant pas notre site pour Referer, est sûrement l'objet d'un vol de bande passante… C'est cette caractéristique que nous allons exploiter avec ce code qui peut aussi bien être, comme toujours, dans un .htaccess qu'un fichier de configuration Apache.

Ce qui se passe c'est que si le Referer est bien notre site, nous positionnons une variable acces_local à 1. Ensuite nous ajoutons une règle qui interdit le téléchargement des images (Deny from all) sauf pour les requêtes qui ont la variable acces_local définie. Voilà, c'est tout. La directive FilesMatch est elle là pour n'opérer cette sécurité que sur les fichiers images, feuilles de style, scripts, etc. Il serait en effet un peu idiot d'appliquer cette règles au fichier .php par exemple, cela interdirait systématique l'accès du site à tout le monde….

Empêcher certains navigateurs

Vous aurez remarqué dans l'exemple précédent la syntaxe un peu étrange du paramètre de la directive SetEnvIfNoCase. On appelle cela une expression régulière . Une expression régulière est une sorte de motif permettant de décrire une chaîne de caractère attendue. On peut ainsi créer des expressions régulières décrivant un numéro de téléphone ou une adresse courriel. Dans l'exemple précédent, elle signifiait "toute les URL qui commencent par (symbole ^) http://www.monsite.net/". Les \. étaient là pour indiquer que l'on voulait que le vrai caractère . soit utilisé, car sinon, ce symbole a un sens particulier dans une expression régulière.

Maintenant imaginons qu'un vilain spammeur qui me fasse des misères et que son adresse IP varie de 81.95.144.X à 81.95.147.X. Je peux le bloquer par la configuration suivante :

C'est à peu prés le même exemple que précédemment sauf que cette fois on utilise, non pas Referer mais Remote_Addr qui est l'adresse IP du navigateur client. Je ne vais pas faire ici un cours sur les expressions régulière, il y a de magnifique tutoriaux sur ce sujet.

Juste un dernier exemple, si cette fois c'est la chaîne d'identification ( User Agent ) d'un navigateur que je veux bloquer, par exemple un bot malveillant :

Là, j'utilise une directive un peu spéciale qui a le même rôle que les précédentes mais cette fois sur la variable User_Agent sans distinction de majuscules/minuscules.

Bien évidement, vous pouvez mettre une liste complète de définitions avant d'insérez votre directive Deny :

Cette méthode n'est pas aussi fiable que je le voudrais car les adresses change, et les chaînes d'identification de navigateur aussi. Mais au moins est-ce un moyen de contrer efficacement une attaque ponctuelle. Pour une liste complète des directives touchant à la définition de variables, je vous renvoie à la documentation d'Apache.

Protéger par adresse IP

Même si cela fonctionne, passer par les variables pour interdire une IP avec des expressions régulières est un peu sauvage pour un usage courrant. Si vous voulez pour votre dossier, ne soit accessible que pour une seule IP, ou un groupe d'IP, nous pouvons plus simplement utiliser la directive Deny From. Par exemple ici, pour n'autoriser que l'IP 192.168.0.10 nous utiliserons la configuration suivante :

Nous pouvons assouplir la règle en enlevant un group de chiffre à la fin de l'IP. Par exemple Allow from 192.168.0 autorise les adresses allant de 192.168.0.0 à 192.168.0.255, à se connecter.

Mixer les plaisirs

Pour finir, un petit mélange. Imaginons que nous protégions notre dossier par mot de passe via LDAP mais qu'en même temps nous ayons besoins que les clients se connectant d'un adresse IP spécifique, puise le faire sans mot de passe. Cela nous donnerais le code suivant :

Rien d'inconnu maintenant dans ces syntaxes, à l'exception de la dernière ligne, qui fait toute la différence. En effet, elle indique à Apache que l'une ou l'autre des conditions suffit à autoriser l'accès : soit l'IP, soit le mot de passe.

Conclusion

L'article est déjà long et nous sommes loin d'avoir totalement couvert le sujet. J'espère seulement que cela vous donnera assez de pistes pour trouver la solution qui convient le mieux à vos besoins. L'agressivité et l'automatisation des attaques comme en témoignent souvent les fichiers de traces, prouvent que ce genre de précaution est simplement obligatoire. Il n'y a à ma connaissance pas de moyens systématique de valider qu'un serveur est correctement fermé, et ce qui est réellement ouvert. Google permet par le biais d'une requête de type site:mon-site.com d'avoir la liste de ce qu'il voit mais cela se limite à ce qui a été lié, quelque part, sur le Web, ce qui est loin d'être suffisant.

Car croire que le seul fait de ne pas publier sur le web le lien vers un dossier le rend invisible est pure crédulité comme en témoigne cette ânerie là, , que j'avais trouvé par hasard, en bidouillant l'URL d'annulation d'un courriel de pub, sans l'aide google.

Petit billet à destination de ceux qui s'intéressent aux productions libres disponibles sur ce site.

Dans la catégorie "généralités", j'ai vaguement torpillé le module Drupal contrib Project pour le faire un peu mieux coller à mes besoins. La présentation des projets est maintenant sur une seule page, avec un ensemble de sections standard :

• Licences
• Téléchargement des versions binaires
• Documentation (s'il y en a une
• Accès aux sources via Subversion
• Liste des anomalies par projet et soumission de nouvelles (il faut avoir un compte)
• Liste des fonctionnalités demandées et soumission de nouvelles (il faut avoir un compte)

Ça se passe donc dans Artisanat , par le menu en haut du site, à côté de thèmes dont voici les nouveautés et choses à venir.

TuxDroid

Ce matin, j'ai mis à jour l'ami TuxDroid avec une moyenne bonne surprise. Le démon TTS (parole) semble avoir changé et l'API ne peut plus s'y connecter. J'ai modifié le reste pour qu'il fonctionne avec le démon tuxd (mouvements, senseurs, etc) et là tout est revenu à la normale, mais pour le langage, il va falloir que je me penche un peu plus avant sur la question de ce qui a bougé et donc sur le nouveau démon fournit dans TuxSetup 1.3.<.p>

Donc pour ceux qui voudraient utiliser le reste, la version trunk est mise à jour, il faut juste recompiler.

Au passage, suite à pas mal de cris, j'ai viré Maven2 du système de construction, pour repasser à un bon vieux ANT. J'ai aussi rajouté une note (Merci à Garf de me l’avoir fait remarquer) pour ne pas oublier de télécharger aussi les sources de Java Commons Library.

Pour finir sur le Tux, une nouvelle sympatoche, en plus d’avoir (enfin) reçu mon TShirt TuxDroid officiel, j'ai été contacté par la société Kysoh.

Leur équipe de développement est en train de réaliser un nouvelle architecture de démons qui communiqueraient un peu dans la ligne de ce dont on avait longuement discuté avec Jaguarondi, l'auteur de ce qu'il y a dans le ventre du tux (Rémi, c'est la conversation dont je te parlais et sur laquelle je ne mettais plus la souris). Donc, à priori, les démons ne seront non plus accessibles en Socket/Trames Binaire mais plus simplement par HTTP/XML. Grande évolution qui va en gros diviser par 10 le code de l'API et surtout permettre de réaliser des API à la chaîne pour des langages plus diversifiés (y compris Javascript).

De mon côté je vais donc, en plus de la nouvelle API Java qu'il va falloir porter vers la nouvelle architecture, développer pour Kysoh, mais en modèle libre, une partie de mon ancien TuxletManager vers la nouvelle API des Gadgets. Le tout devant s'intégrer dans un GadgetManager... tout en Java

Voilà. Fin des niouses pour le Pingouin mécaniques

Java Commons Library

J'ai été surpris d'apprendre que je n'étais pas le seul à l'utiliser. Comme beaucoup des choses se trouvant dans la catégorie Artisanat Locale, la raison d'origine qui m'avait fait publier ce code était de forcer un peu mes clients à contribuer au libre lorsqu’ils étaient content que j’arrive avec des briques toutes faites pour leur projet. Et comme ces pages sont goulûment mangées par google, ces derniers ne pouvaient pas soutenir ensuite que les dites librairies leur appartenait… Ne riez pas, cela m'est arrivé une fois, j'ai du tout ré-écrire ).

Mais si d’autres l’utilisent, ça change un peu la donne et j'ai donc décidé de la couper en deux. J'ai extrait au maximum les choses trop bancales, pour n'y laisser que les fonctionnalités les plus pérennes (librairies Shell et XML notamment). J’ai mis la liste des changements à jour pour refléter cette évolution.

En tout cas, heureux de voir que cette librairie puisse être utile à certains !!

Drupal WEBDav Module

Si le support WEBDAV pour Drupal donné par ce module est dors et déjà opérationnel, il est encore lent et buggé. J'avais été contacté en Novembre dernier par quelqu'un devant m'aider sur le projet. Mais comme cela m’est arrivé trop souvent, le garçon c’est un peu éclipsé au milieu du gué… Là je vais donc tenter de fusionner et achever ses modifications et en profiter pour optimiser le tout et basculer un système de hooks permettant à la communauté Drupal de développer des supports WebDav pour tout et n’importe quoi.

La librairie perl "Suza"

A l'origine cette librairie regroupais deux trois choses que j'utilisais régulièrement en perl, sorte de boite à outils Perl. Lorsque j'ai travaillé en Décembre avec Dab sur la distribution française pour Zaurus, ZaurusFR (qui marche du feu de dieu d'ailleurs, chapeau Dab !!), cette librairie a pas mal évolué. Mais vu que j'utilise Perl de moins en moins, je pense que le projet va simplement « voler » pour être définitivement intégré à la distribution de Dab. Cela ferra une dépendance en moins

Conclusion

Voilà, fin des niouses sur le sujet des productions locales, ne reste plus qu’à faire son marché

Lorsque l'on est amené à bosser chez un client, il est très rare d'avoir accès au net autrement qu'à travers un proxy type Squid . Le problème avec cette situation et que l'on expose ainsi nos données à des regards indiscrets. Le but de ce tutoriel est donc de vous proposer une solution pour palier à cela.

Un proxy ?

D'un point de vue général un proxy est un bout de logiciel qui va recevoir vos demandes réseau et les retransmettre, après un éventuel traitement, à qui de droit. Il existe de nombreux types de proxy mais en entreprise il s'agit très souvent d'un proxy type HTTP . Le principe est que chaque requête HTTP est envoyé par le navigateur au serveur Proxy qui va tout d'abord en examiner la légitimité et renvoyer une erreur si l'on cherche à atteindre une URL interdite. Ensuite le proxy va effectuer la vraie requête vers l'URL demandée et recevoir la page résultat. Généralement, et c'est le second rôle d'un tel proxy, cette page va être stockée en local sur le disque du serveur, avec tous les fichiers associés (feuilles de style, images, etc.). Le proxy va enfin renvoyer la page stockée en local au navigateur.

Ainsi un proxy permet à une entreprise de limiter l'utilisation d'Internet au seul WEB, de filtrer les accès pour ne pas autoriser les sites n'étant pas en rapport avec le travail (blog, sites de jeu et j'en passe), enfin réduire les besoins en bande passante stockant une copie des pages en local.

Maintenant, d'un point de vue "utilisateur" cette approche a l'inconvénient de ses avantages. On ne peut aller où l'on veut. On ne peut utiliser autre chose que le WEB (IRC, Messagerie instantanée, etc.), et surtout, l'ensemble des pages visitées, des mots de passe utilisés est tracé et stocké.

Accès sécurisé

Fort heureusement, il existe une parade à cette approche : l'accès au WEB sécurisé via HTTPS . En effet, il est rare que ce mode de connexion à la toile soit bloquée tant cela deviendrait contraignant pour l'utilisateur (aucun accès à une zone abonnée chez un éditeur, à une banque, etc.). Or le HTTPS est absolument impossible à filtrer par le proxy d'entreprise dans la mesure où toutes les données circulent d'un un tuyau crypté dont la clef de décodage n'est partagée qu'entre vous et votre serveur cible. Ceci dit il est toujours possible de créer un proxy qui vous fasse croire que vous êtes en communication sécurisée avec votre serveur mais je n'ai pas entendu parler d'une telle implémentation en standard.

Ainsi donc, dés que vous accédez à un site en HTTPS, le proxy devient aveugle, il ne stocke plus les pages en local, ne voit plus les mots de passe, mais il peut toujours voir les URL. De plus, tous les sites auquel nous voudrions accéder n'ont pas forcement un accès HTTPS de disponible. Pour exploiter cela nous avons plusieurs possibilités.

PhpProxy

Techniquement, une méthode qui permettrait de court-circuiter totalement un proxy serait de passer par un service type anonymizer. En effet, ce type de site est accessible en HTTPS et permet dans une zone de la page de rentrer l'URL "interdite". Ces sites fonctionnent comme notre proxy d'entreprise et vont chercher, eux-mêmes les données, pour les renvoyer sur leur propre page.

Si cette méthode marche pour vous, c'est parfait, d'autant plus qu'il existe de nombreux site du même genre, il suffit de demander cela à google. Cependant cette approche pose deux problèmes. Le premier est que les administrateurs de votre proxy d'entreprise ne sont pas idiots et ont sûrement la liste exhaustive des services publiques d’anonymisations indiquées comme URL interdites dans le proxy. Et si ce n'est pas le cas, l'autre soucis est que si ce n'est plus l'entreprise qui peut voir où vous aller, ce site dont vous ne savez rien, lui, le peux.

La solution ultime consiste donc à monter son propre service d'anonymisation. Pour cela deux pré requis : disposer d'un serveur WEB équipé de PHP accessible d'une IP publique et que ce serveur soit accessible en HTTPS. Le cas échéant, vous pouvez utiliser votre propre ligne Internet personnel en installant chez vous un serveur Apache/PHP et en utilisant un service du genre de celui que propose dynDNS. Pour ce qui suit, je pars du principe que vous avez la main sur un serveur unix avec apache, https (mod_ssl) et PHP correctement installés.

La marche à suivre est très simple. Tout d'abord télécharger phpProxy. Décompressez le dans le dossier de votre choix (ex. /documents/web/phpProxy). Ensuite, ajoutez à la configuration du vhost https quelque chose du genre : Alias /farfelu /documents/web/phpProxy SSLRequireSSL Options Indexes FollowSymLinks MultiViews IncludesNoExec AddOutputFilter Includes html AllowOverride All AuthType Basic AuthName "Accès à Farfelu" AuthUserFile /usr/local/apache/passwd/passwords Require valid user

Les points important ici sont que nous créons un alias /farfelu car il ne serait pas très malin que l'URL d'accès à votre proxy soit /mon_proxy . Ensuite le SSLRequireSSL qui oblige l'utilisateur de cette URL à passer par HTTPS. Enfin, trèèèèès important, ajoutez un identifiant/mot de passe sur cette URL si vous ne voulez pas que quelqu'un tombant dessus par hasard, puisse utiliser votre proxy à votre insu pour faire des choses répréhensibles. Si vous êtes un peu paumé avec ces options, vous pouvez faire un tour ici.

Une fois qu'apache a été redémarré, il ne reste plus qu'à tester notre URL https://mon_serveur_publique/farfelu. Si tout fonctionne correctement, vous devriez obtenir quelque chose conforme à l'illustration.

Après l'utilisation est relativement intuitive, plusieurs options permettent de modifier le comportement du proxy comme la possibilité de supprimer les JavaScript, gérer les coockies, etc.

Utilisez la commande CONNECT

HTTPS implique une connexion directe entre vous et le serveur cible. Pour que cela puisse fonctionner, existe une commande CONNECT dans la norme du protocole HTTP. Cette commande indique au proxy que l'on désire établir une connexion directe avec la cible, en se passant de ces services. Autant dire qu'il s'agit là d'un magnifique trou dans lequel il est possible de s'engouffrer.

Dans la norme HTTP, rien n'interdit de donner le port de son choix à la commande CONNECT. De fait il devrait donc être possible de se connecter, via cette "faille", à un serveur distant SSH, écoutant classiquement le port 22. Cependant ce n'est pas aussi simple. Pour limiter la casse, les proxy interdisent généralement une commande CONNECT qui chercherait à atteindre un port autre que le 443, qui est le port "officiel" d'HTTPS. La conséquence pour vous, est que pour exploiter cette "faille", il faut obligatoirement que votre serveur SSH soit en écoute du port 443, rendant du coup l'utilisation de cette astuce incompatible avec l'utilisation conjointe d'un Apache en HTTPS. Si vous n'avez pas ce problème, nous pouvons poursuivre.

Mettre un ssh en écoute sur le port 443 ne pose aucun problème en soit. Il suffit pour cela de modifier le fichier de configuration /etc/sshd_config et d'y placer ou modifier le paramètre Port 443. Après redémarrage, un netstat -anlo | grep 443 nous confirme bien que SSH est en écoute sur le port HTTPS.

Vous pouvez aussi doubler les ports en écoute par le serveur SSH en utilisation xinetd. Après l'avoir installé, il faut désactiver le service sshd (par un chkconfig -del sshd) . Ensuite vous allez modifier /etc/xinetd.d/sshd-xinetd de sorte à avoir un disabled=no. L'étape suivant consiste à simplement dupliquer ce fichier dans le même répertoire sous le nom sshd-xinetd-https et l'éditez pour changer la ligne service ssh en service ssh-https. Enfin, indiquez le port de connexion de ce nouveau service en éditant le fichier /etc/services et ajoutant à la fin ssh-https 443/tcp. Un petit redémarrage de xinetd cette fois et ssh devrait être accessible des deux ports 22 et 443.

Maintenant, pour se connecter à travers un proxy HTTP, sur un serveur Serveur SSH, nous avons besoin d'un client capable de causer avec le proxy et donc de générer cette fameuse commande CONNECT. Pour Windows, rien de plus simple, il suffit pour cela d'utiliser PuTTY. On prendra alors soin, dans le paramétrage de la connection, à la section proxy, de bien sélectionner HTTP, ainsi qu'indiquer l'adresse et le port du dit proxy.

Ensuite, dans les coordonnées du serveur cible, il faut bien sur renseigner le nom ou l'IP du serveur cible, et surtout changer le port pour utiliser le 443. Sauvegardez la connexion et cliquer ensuite sur Open. Si le proxy est suffisamment ouvert, il devrait vous laisser passer et vous aurez un login.

Pour faire la même chose d'un client Linux, il suffit d'installer le paquet corkscrew. Ensuite la commande est très simple :

Là aussi, si tout va bien, vous devriez pouvoir vous connecter. A partir de là vous pouvez faire à peu prés ce que vous voulez, y compris mettre en œuvre un proxy SOCKS.

Tunnel HTTP

Autre option, utiliser cette fois le vrai protocole HTTP, sans truquage. La magie est à mettre ici au compte de HttpTunnel. Sur le site vous trouverez les binaires pour Windows, et pour Linux, tout est généralement dans votre distribution à partir d'un urpmi ou apt-get httptunnel.

HttpTunnel se compose de deux parties. Un serveur et un client. Le client va se mettre en écoute d'un port local et rediriger toute demande vers le serveur, en prenant soin de tout encapsuler dans du HTTP classique. De l'autre côté, le serveur HttpTunnel va recevoir les demandes, décapsuler les données contenues dans les trames HTTP, et rediriger le tout vers le port de votre choix.

Par l'exemple, imaginons que sur la machine SERVEUR, nous ayons un service SSH qui tourne en écoute du port 22 (classique). Nous allons donc lancer notre serveur HttpTunnel :

Le serveur HttpTunnel est donc en écoute du port 80 (HTTP) et décapsulera tout ce qu'il recevra vers le serveur SSH en écoute du port 22. Maintenant du côté client :

Le client va ainsi utiliser le proxy HTTP de manière standard, pour contacter le serveur HttpTunnel qui se trouve à l'adresse IP indiqué et au port 80. J'utilise l'adresse IP car le nom de la machine semble ne pas toujours fonctionner chez moi.

Maintenant que notre tunnel est en place, reste à l'utiliser et à lancer un

Et là magie, avec un temps de réaction qui m'a clairement surpris, tout fonctionne. Ici aussi, disposant d'un SSH classique, il est possible de mettre en œuvre ensuite un mini proxy SOCKS.

Maintenant cette méthode a beau très fonctionnelle, elle présente de nombreux inconvénient. Tout d’abord elle squatte le port 80, ou au mieux le 8080 si votre Proxy l’autorise. Il semblerait qu’il n’y ait aucun moyen de changer cela, y compris en utilisant une combinaison Apache/VHOST/ReverseProxy.

Enfin, il n’y a aucune authentification. C’est un système ouvert aux quatre vents. Et ça c’est déjà plus sérieux.

AjaxTerm

Pour finir, personnellement ma méthode préférée, en conjonction avec phpProxy. Car si ce dernier me permet d'aller où je veux, AjaxTerm va me permettre de faire ce que je veux. Et le tout, comme PhpProxy, sans configuration compliquée et avec un simple navigateur WEB.

Cet outil est tout simplement un terminal totalement fonctionnel, colorisé, réactif qui fait presque oublier que l'on est en réalité dans un navigateur. Toutes les applications type nCurse fonctionnent, toutes les commandes sont disponibles, il n'y a tout marche comme à la maison, y compris la tabulation pour compléter les commandes. Que demander de mieux ?

Côté installation, AjaxTerm est un serveur écrit en pyton disponibles dans vos dépôts sans aucun doute via un urpmi/apt-get ajaxterm. Ensuite il n'y a plus qu'à lancer le service du même nom : /etc/init.d/ajaxterm start. Par défaut le serveur se met en écoute du port localhost:8022. Il n'est donc pas disponible directement à partir du réseau public, et c'est tant mieux. Car nous allons du coup pouvoir utiliser un reverse proxy apache pour le coller dans notre conteneur HTTPS, avec le cryptage et l'authentification qui va bien. Le tout au côté de nos autres applications WEB, sans conflit.

Une fois le serveur lancé, vous pouvez vérifier son fonctionnement avec un navigateur WEB en allant sur http://localhost:8022. Une fois que vous avez constaté son bon fonctionnement, il faut rajouter dans la configuration d'apache, de préférence dans le vhost en charge du port 443/HTTPS, les lignes suivantes. Pour les détails sur les paramètres d'authentification, se reporter à ce billet .

Maintenant pour que cela fonctionne, assurez vous que vous avez installé le module apache apache-mod_proxy. Après un petit redémarrage d'apache et l'on peut se connecter du monde extérieur, de manière sécurisée et authentifié, à l'adresse http://mon_server/mon_machin/. Remplacez mon_machin dans la configuration par quelque chose de plausible mais n'attirant pas l'attention. Evitez les choses du genre /je_vous_ai_bien_eu/, ça ne va pas le faire bien longtemps

Ne laissez pas non plus la console activée en permanence car étant de l'ajax, je soupçonne qu'il fasse sur le serveur des requêtes récurrentes qui pourraient attirer l'attention.

Conclusion

Voilà, c'est la fin de la seconde édition de ce tutoriel, avec mes remerciements aux gens en dessous (Dab & co ) qui m'ont donné suffisamment d'idée pour ne pas en rester à un simple proxy en php

L'objectif de ce tutoriel est de pouvoir re-créer une image ISO étendue (augmentée de fichiers, pilotes, etc) à partir d'une image ISO existant ou encore de créer une ISO amorçable à partir des seuls fichiers du CD d'origine. L'utilisation de cette technique est multiple mais pour l'exemple, nous allons l'appliquer à la création d'un CD windows amorçable à partir d'une archive du type de celles fournit par Microsoft et ne contenant que les fichiers d'installation.

Préparation des fichiers

Pour commencer, il nous faut créer un dossier, disons bootable pour faire dans l'originalité. Dans ce dossier nous allons décompresser l'ensemble des fichiers présents dans l'archive d'installation.

Si l'objectif est de recréer un CD contenant plus de pilotes, ou des correctifs, la même recopie peut être faire à partir du CD original ou d'une image ISO de celui-ci que l'on aura monté par un mount image.iso point_montage -o loop.

Les opérations de copie et de mis à jour terminée, nous pouvons passer à l'étude du point délicat de l'histoire, l'image d'amorçage du CD.

Mâter le Torito

Pour la petite histoire, l'extension de la norme ISO9660 du CD-ROM est étendue par un autre norme, nommée El Torito qui elle décrit la manière de démarrer sur le CD-ROM. Physiquement, cela correspond à un secteur du CD contenant les 2048 octets d'un programme d'amorçage. Ce programme est spécifique à l'OS que l'on cherche à utiliser et même parfois à sa version.

Pour créer notre image ISO, nous allons avoir besoin de ce programme sous la forme d'un fichier (une image). Pour Windows, vous pouvez récupéré cette image ici, cherchez dans la page le lien version un fichier cdsector.bin. Mais si cela ne fonctionne pas, vous pouvez toujours l'extraire à partir d'un CD original.

L'opération est un peu plus compliqué qu'il n'y parait car la position de ce secteur n'est pas fixe, elle se calcule. Du coup, pas possible d'utiliser simplement la commande dd sans l'avoir préalablement repéré. Heureusement, il existe un script perl qui fait cela très bien, disponible ici. Il s'utilise très simplement comme cela :

Si vous n'avez pas l'image ISO de votre cd, sachez qu'elle peut très facilement être extraire par la commande dd :

Si tout c'est bien passé, nous avons notre image de démarrage qui fait très exactement 2048 octets, dans notre dossier bootable. Passons à la création de l'image ISO à proprement parler.

Création de l'image ISO

A ce stade, nous avons tous nos fichiers dans le dossier bootable et notre image el torito en bootable/BOOT.IMG.

Nous allons maintenant utiliser l'indispensable mkisofs disponible dans toutes les distributions pour compiler notre dossier en une image ISO :

Au bout de peu de temps, mkisofs a compilé l'ensemble des fichiers en une image ISO amorçable que vous pouvez tester avec VirtualBox par exemple.

Une fois l'image validée, vous n'avez plus qu'à la graver :

Suite à la migration vers gnome (voir ici), trouver des remplaçants pour toutes les applications KDE que j'avais l'habitude d'utiliser n'a pas posé de gros problèmes, sauf pour le lecteur de courrier électronique kmail. Et après avoir essayé divers lecteurs, aucun ne me convenant vraiment, j'ai donc décidé de jeter à nouveau un oeil sur un outil que j'avais laissé de coté il y a longtemps, thunderbird.

Bien entendu, le lecteur attitré à gnome, evolution, fonctionne sans problèmes mais deux choses me gênent dans ce lecteur. D'une part son apparence visuelle (question de goût - c'est sûrement paramétrable mais d'emblée je ne suis pas emballé) ; d'autre part un petit souci de SMTP : j'utilise deux STMP différents selon que je suis à la maison ou au boulot, et ce, avec plusieurs comptes email différents. Or à la base, evolution associe à chaque compte un SMTP fixé.

Bon ok, pour contourner le problème des STMP multiples, il est possible de créer deux fois le même compte en associant chacun à un SMTP différent mais ce qui me plaisait sous kmail, c'était la possibilité de choisir à l'envoi le SMTP que je souhaitais utiliser.

Importer les messages de kmail

La FAQ de thunderbird explique qu'il suffit de créer une boite temporaire au format mbox dans kmail et d'y mettre l'ensemble des messages que l'on veut importer, appelons ce dossier temporary. On copie ensuite ce dossier dans l'arborescence de thunderbird, normalement dans ~/.thunderbird/xxxxxx.default/Mail/Local Folders/ et, ô magie, la boite apparaît dans l'arborescence de thunderbird.

Alors il faut être un peu plus précis (à moins que je n'ai loupé la manip) : en fait, dans ~/.kde/share/apps/kmail/mail/, il faut aller en réalité dans .temporary.directory, qui n'est donc pas un dossier visible lors d'un simple ls. Et c'est le fichier temporary que contient ce dossier caché qu'il faut déplacer vers l'arborescence de thunderbird.

Autre problème : si temporary contient lui-même des sous-dossiers, ils ne seront pas vus par thunderbird pour la même raison : il faudra recopier le contenu des sous-dossiers cachés. Encore une fois, j'ai peut-être foiré la manip d'export ... mais après ces quelques péripéties toutes mes boites sont importées sans problèmes.

Les SMTP multiples sous Thunderbird

Sous thunderbird, on peut déclarer autant de SMTP indépendants que l'on souhaite, en sachant qu'il y en a un d'utilisé par défaut pour l'envoi du courrier. Ensuite, chaque compte peut utiliser le SMTP qu'il souhaite, soit celui par défaut, soit un autre bien précis : il suffit, dans la gestion du compte, de cocher le SMTP voulu. Vous allez me dire que cela ne résout pas vraiment mon problème puisque cette méthode m'oblige à reconfigurer mon SMTP par défaut à chaque fois que j'arrive au boulot, ou que je rentre à la maison. Pas pratique.

C'est aussi ce que je me suis dit, et après quelques recherches je suis tombé sur un petit plugin sympa : Buttons!. L'intérêt premier de ce plugin est de permettre l'ajout de tout un tas de boutons dans les barres d'outil de thunderbird. Je n'ai pas tout exploré, mais le bouton qui m'a de suite intéressé, c'est celui qui permet un raccourci aux différents SMTP configurés. Pour ma part, je n'ai installé ce bouton que sur la fenêtre de rédaction des messages (voir photo).

Un click sur le bouton "SMTP" permet d'accéder aux paramètres des SMTP, mais plus simplement si on clique sur la flêche associée au bouton (juste à droite de celui-ci), on peut alors directement choisir le SMTP à utiliser pour l'envoi du message. C'est exactement ce que je souhaitais

Iconification de Thunderbird

C'est bien pratique de voir dans le systray si des nouveaux messages sont arrivés ; or thunderbird, par défaut, ne possède pas ce système de mise en icone dans la boite des miniatures, comme tout bon lecteur de mail gnome ou kde. Qu'à cela ne tienne, deux options s'offrent à nous.

La première consiste à utiliser un petit paquet s'appelant alltray qui est sûrement disponible chez votre fournisseur habituel de paquetages. Le principe de alltray est de pouvoir iconifier tout ce que vous souhaitez pour rendre la fenêtre visible ou invisible en cliquant sur la miniature. C'est évidemment surtout utile pour des applications non gnome ou non kde (firefox, par exemple).

Petit inconvénient tout de même : alltray ne permet pas le changement de statut de la miniature, par exemple l'arrivée de nouveaux messages n'en change pas l'aspect, ce qui est un peu gênant. Mais pour d'autres applications, c'est un outil intéressant il me semble.

Deuxième solution : on se tourne à nouveau vers un plugin ; et celui qui correspond à mon besoin s'appelle moztraybiff. Ce plugin iconifie thunderbird dans le systray et l'arrivée de nouveaux messages modifie la miniature (cf. photo). Seul petit inconvénient : fermer la fenêtre thunderbird ne le laisse pas dans la boite à miniature, mais ferme réellement l'appli. Il faut donc ne cliquer QUE sur la miniature pour basculer entre le mode visible/caché. Au fond, c'est plus naturel, mais ça demande un petit temps d'adaptation.

Personnalisation de l'interface

Dernier point : on peut tout çà fait modifier l'apparence de thunderbird via une feuille CSS. Il faut pour cela (s'ils n'existent pas) créer un dossier chrome dans ~/.thunderbird/xxxxxx.default et y mettre dedans la feuille de style sous le nom de userChrome.css (attention aux majuscules/minuscules pour le dossier et le fichier).

Je ne vais pas rentrer en détail dans toutes les possibilités de personnalisation qui sont nombreuses, voici deux liens qui font le point sur les différentes classes pouvant être stylisées : mozzilla.org et linnhe web site.

Conclusion

Au final, thunderbird convient parfaitement à mes besoins d'utilisation grâce à l'utilisation de plugins, ce qui est de façon générale l'un des gros points forts des appli mozilla.

Pas besoin donc de me torturer avec evolution que je ne porte pas dans mon coeur, et je peux définitivement laisser de coté tout résidu de KDE, ce qui permet d'avoir un ensemble plus homogène.

L’OOXML, ce format de document bureautique poussé par Microsoft, devenu après moultes péripéties une norme ISO, semble aujourd'hui bien parti pour devenir la langue numérique officielle de la "République" Française. C'est un peu anticipé, certes, mais que penser d'autre de cette étrange séquence d'événements…

Petit introduction des acteurs

Avant de commencer, introduisons rapidement les acteurs de cette formidable histoire en commençant par la Direction Générale de Modernisation de l'Etat (DGME) qui, comme son nom l'indique, a pour mission de moderniser l'administration en général, et son aspect numérique en particulier. Précisons que la DGME dépend du Ministère du Budget, des Comptes publics et de la Fonction publique, autrement dit… de Bercy.

En 2005 a été confié à la DGME le pilotage du projet ADELE (projet d'Administration ELEctronique) qui va prendre en charge des sujets aussi divers que l'archivage numérique, identité numérique, etc. Les missions de l'ADELE sont :

• Simplifier la vie de l'usager dans sa relation à l'administration
• Améliorer l'efficience du service public
• Valoriser l'agent public dans sa mission

L'ADELE est très fortement liée au monde libre (quelle meilleure manière de valoriser l'argent publique) et met même en œuvre une plate-forme de développement collaboratif, Admisource alias la Forge d'ADELE. Tout un symbole.

Mais un projet encore plus ambitieux est pris en charge par l'ADELE : le Référentiel Général d'Interopérabilité (RGI). Ironiquement soutenu par les acteurs du libre en France, le RGI vise à définir l'ensemble des règles partagées entre les acteurs de l'administration, format bureautique compris. Pour saisir son importance, il faut bien comprendre que contrairement à l'ancien CCI (Cadre Commun d'Interopérabilité), le RGI a force d'obligation. Toutes les administrations sans exception devront s'y soumettre. Et le seul format de document bureautique capable de répondre au critères d'interopérabilité exigé par le RGI, est l'OpenDocument (voir la version 0.90 du RGI, page 30).

C'est donc bien là que l'histoire semble commencer à s'envenimer. On pouvait même, en prêtant l'oreille, entendre des dents grincer par delà la grande marre…

Référentiel bloqué

Mais le 12 Octobre 2007, le projet RGI, sans raison, s'arrête brutalement. De vilains colporteurs de rumeurs parlent alors d'un certain éditeur qui, aidé de certaines administrations locales et d'une erreur de procédure lors de la rédaction du premier texte, aurait fait pression pour mettre le projet en sommeil quelque temps. Il faut dire que pour Microsoft le ciel français n'est pas des plus clément car au-delà de l'évincement de son format du RGI, la France par le biais de l'AFNOR vote pour l'instant "non" clair et franc, à sa normalisation par l'ISO. Tout temps gagné est donc bon à prendre…

Et ce ne fût pas mauvaise stratégie car au 1er Avril, coup de théâtre, contre toute attente, du jour au lendemain (c'est à peine exagéré) la France choisit finalement… de s'abstenir.

A la lumière des contributions et des commentaires, il nous est apparu qu'une "Désapprobation" n'était plus justifiée. Pour autant, il demeure encore des incertitudes sur les textes et les engagements, ce qui nous a conduit à nous prononcer par une "Abstention"

(Tony Hittema, directeur technique de l'Afnor. Source: Les Echos).

Alors que peut motiver un si brusque changement de position de la part de l'AFNOR ? Quelles sont ces mystérieuses contributions et commentaires ?

D'un "NON" franc à une étrange abstention

Il y en a eu plusieurs contributions en réalité : la position d'HP, cette de Patrick Durusau (éditeur du projet ISO pour l'OpenDocument), et enfin une lettre d' Eric Boustouller, Président de Microsoft France adressée à l'Afnor.

Je passerais rapidement sur la position de Hewlett-Packard qui a à peu près autant de compétences sur le sujet qu'un fabriquant de bocaux sur l'art de faire un confit. La position de P. Durusau, contient quant à des assertions assez sympas du genre OOXML est plus avancé qu'ODF, donc si OOXML n'est pas normalisé, ODF disparaîtra.. Très fin, très poussé, très technique donc… passons… Reste enfin la lettre d'Eric Boustouller qui est en soi un très bel exemple de déclaration d'intention. Reste encore à y croire.

En somme, les fameuses contributions nous laissent quelque peu sur notre faim. Et pourtant ce serait bien ces éléments qui officiellement auraient fait changer la position de la DGE et de la DGME, et donc de l'Afnor, d'un "NON" convaincu à une "abstention"… qui semble comme dictée par quelque chose d'autre.

Même l'APRIL n'y croit pas et moi, pour trouver une raison, j'ai du bien mal à m'empêcher de suivre le fil d'Ariane qui mène de la DGME à Bercy, de Bercy au ministère des Finances, et de ce ministère au cabinet de la présidence de la république…

Du trépas d'ADELE à la résurrection du RGI

Mais laissons mes délires paranoïaques de côté un instant pour avancer un peu dans le temps, le 11 Avril. La communauté est réunie pour salon Solution Linux et va apprendre une bien triste nouvelle, la DGME se retire du libre en annonçant le décès d'ADELE…

Le programme ADELE est prévu pour s’échelonner sur 4 ans de 2004 à 2007. Il est terminé et il n’y plus de programme Adele en tant que tel. La DGME est en train de modifier ses missions vers un accouplement des ministères, vers la mise en œuvre de la réforme générale des politiques publiques, nouveau programme de modernisation et de transformation de l’État. Et donc pour l’année prochaine les conférences ADELE n’ont plus lieu d’être

Voici donc le nouveau programme de modernisation en route, paix à l'ancien plus libre mais moins lucratif. ADELE est quant à elle… enterrée. Mais une question subsiste, que va devenir le lourd sommeil du RGI ?

En bien la réponse ne se fait pas attendre. Le 16 Avril, voilà que par miracle, la machine RGI se remet brutalement en route et avec un surprenant dynamisme qui plus est. Mais pas exactement le RGI d'origine, un modèle modifié, amélioré diront certains, intégrant maintenant fièrement Microsoft/OOXML aux côtés d'OpenDocument.

A ce stade, seules de sombres suppositions permettaient d'imaginer ce qui jusqu'alors bloquait le RGI. Mais c'est finalement un chef de service de la DGME qui coupe court à toute rumeur par un courriel que c'est procuré LeMagIT :

Le projet de RGI présenté lors du dernier comité des référentiels du 12 octobre 2007 avait été mis en attente, suite à la démarche engagée à l’ISO par l’ECMA concernant le standard OpenXML. Cette démarche ayant maintenant abouti, nous en avons tenu compte et nous souhaitons engager sans délai la démarche de validation du RGI, pour une présentation du projet aux assises du numérique de fin mai 2008.

Voilà au moins quelque chose de clair, le RGI attendait "juste" que Microsoft achève sa normalisation pour poursuivre son chemin…

Mes impôts en 2010

Alors certes extrapoler la suite de cette histoire avec Microsoft/OOXML comme langue numérique officielle de l'état, n'est que pure anticipation. Des esprits moins chagrins que le mien verront même sûrement ici une démarche juste poussée par un souci d'égalité. Mais au vu des moyens mis en œuvre, j'avoue manquer d'optimisme. Et je ne risque en tout cas pas de faire des yeux ronds si je reçois un jour ma feuille d'impôts au format Microsoft/OOXML. Feuille d'Impôt qui malgré la normalisation du format utilisé, ne sera bien évidemment lisible qu'avec Microsoft Office 2010.

Dans une première version de cet article, j'avais testé quelques moteurs de rendu GTK pour comprendre cette impression de lenteur que je ressentais de temps à autres. Depuis certains m'ont demandé de tester d'autres moteurs et là je commençais a avoir un panel assez large pour refaire une nouvelle version de ce benchmark.

Protocole de test

Pour tester cela, j'ai utilisé le très pratique gtkPerf. Il n'est pas très évolué mais permet de rapidement tester la majorité des composants GTK en boucle. J'ai donc lancé gtkperf plusieurs fois de suite en utilisant alternant les moteurs, à chaque fois sur le même écran connecté à la même carte vidéo. Les résultats donnés ici sont donc les moyennes sur 4 lancements par moteur.

Résultats

Analyse

Ceux qui avaient lu la première version de l'article peuvent se rappeler que les temps n’étaient pas aussi bas dans tous les cas. Le Core 2 Quad n'est pas étranger à ce "miracle".

Cette fois j'ai trié les résultats du meilleur, celui de Xfce4 encore une fois, au plus lent, eXperience. Si l'on élimine ces extrêmes, cela nous donne tout de même une fourchette allant du simple au double.

Enfin, il faut aussi noter que les moteurs ne sont pas égaux face à la stabilité. Murrrine que j'aimais beaucoup me fait figer Gimp. Smooth fait planter les applications sur certaines boîtes d'ouverture de fichier. Enfin la palme est tout de même à Gtk-Qt qui même s'il n'est pas si lent que cela, provoque des effets de bords assez étonnant comme crasher lors des changements de thèmes justement.

Conclusion

Choisir un moteur est certes une question de goûts, mais sans aucun doute aussi une question de performance et de stabilité. Car au fond, lorsque l'on travaille une journée sur des outils déjà lourds comme eclipse ou openoffice, le côté glamour de l'interface 3D, ombré, transparent, et j'en passe, s'efface bien vite face au besoin de voir l'action se réaliser au moment ou l'on clique.