Vers une informatique de défiance ?

Nous vivons une époque formidable. Mais si ! Depuis des années, on nous parle de sécurisation de l’informatique personnelle. Je suis entièrement d’accord, il faut sécuriser l’informatique, surtout à une époque d’ultra-connectivité.

Cependant, l’énième avatar de cette volonté de sécuriser l’informatique, à savoir la technologie SecureBoot (et l’effet « indésirable » que cela entraînera à terme sur la communauté du libre au plaisir non dissimulée de Microsoft, comme je l’ai exprimé sur un article écrit pour Chatinux), risque de provoquer la naissance d’une informatique où la défiance sera la règle.

Depuis le projet « Palladium » de 2003, tous les efforts pour rendre l’informatique plus sure se résume à rajouter verrous sur verrous, clés sur clés. Depuis la célèbre puce Fritz les efforts ont été constants.

Les verrous numériques ont fait depuis longtemps la preuve de leur inefficacité ou de leur nuisance envers les utilisateurs honnêtes. Les verrous des DVD et des BluRay ont soit été cassés soient contournés. Cette course à l’armement sera sans fin.

Quand on me parle du principe de SecureBoot, qui n’autorise le démarrage que si la clé annoncée par le système d’exploitation est autorisée donc valide, ça me fait penser à une scène du film « Gattaca« .

Dans cette scène, on voit la population « valide » accéder à leurs lieux de travail en se basant sur une goutte de sang, comme une clé pour ouvrir une porte. Des outils vérifient que cette goutte de sang est celle d’une personne qui a le droit d’accès ou pas.

Mais il ne faut pas oublier que d’autres étapes de cette informatique signée existe dejà : par exemple l’AppleStore ou encore la fonctionnalité GateKeeper du futur MacOS-X Mountain Lion.

Car l’informatique dite « de confiance » ne pourra l’être sans une forme minimale de censure. Censure technologique qui sera l’utilisation de clé qui donnera l’autorisation ou non au système d’exploitation de lancer l’application.

D’ailleurs, le principe existe depuis des années sur MS-Windows, avec les pilotes dit WHQL. Cependant, on peut toujours installé un pilote non-WHQL, le système prévenant l’utilisateur.

On ne protègera pas uniquement l’informatique par l’obscurité et l’empilement de verrous plus ou moins solide. Un minimum de pédagogie et d’information est nécessaire.

SecureBoot est une mauvaise réponse à une bonne question : comment éviter que des logiciels vérolés ne démarre sur une machine ?

Et pour finir, je reprendrais la conclusion de mon article sur Chatinux :

Tirons donc notre chapeau à l’enseigne de Microsoft qui en combattant le problème des machines qui pourrait faire démarrer une version frelatée (piratée ?) d’un OS, cela aura comme effet “kiss-cool” de se débarrasser d’un concurrent minuscule : GNU/Linux. Quoique la communauté GNU/Linuxienne s’occupe très bien de son cas toute seule, comme j’ai pu l’écrire sur mon blog personnel, avec un billet teinté d’humour acide.

En voulant conforter l’utilisateur en lui disant : avec telle et telle technologie tu seras à l’abri, cela créera d’abord un sentiment fallacieux de sécurité et engendrera une défiance envers l’outil informatique au final.

Unity sur Archlinux : le retour :)

Ayant entendu parlé via Phoronix de l’existence d’un dépot proposant Unity pour la Fedora Linux j’ai pu lire dans les commentaires qu’il y avait un dépot de paquets à compiler par soi-même pour obtenir unity sur Archlinux.

J’ai donc repris la machine virtuelle créée la veille , et après avoir rajouté alsa, gstreamer, networkmanager, cups et un xorg de base, j’ai en utilisateur classique récupéré le dépot git du port de Unity pour Archlinux :


git clone https://github.com/chenxiaolong/Unity-for-Arch.git

Si on suit le fichier README du portage, il y a quelques chose comme 75 paquets à faire recompiler, dans un ordre précis, même si deux ou trois paquets sont optionnels.

J’avais déjà tenté – sans grand succès – de faire fonctionner unity sur archlinux, le paquet disponible sur AUR est désormais plus que périmé

Et j’ai serré les fesses en lançant la compilation de chaque paquet, sachant que certains paquets officiels sont remplacés par des versions « spécifiques ». Liste non exhautive :

  1. glib2-ubuntu -> glib 2.0 with Ubuntu patches
  2. gtk2-ubuntu -> GTK toolkit 2.0 with Ubuntu patches
  3. gtk3-ubuntu -> GTK toolkit 3.0 with Ubuntu patches
  4. qt-ubuntu -> Qt toolkit with Ubuntu patches
  5. gconf-ubuntu -> A configuration database system
  6. gsettings-desktop-schemas-ubuntu-> Shared GSettings schemas for the desktop
  7. gnome-settings-daemon-ubuntu -> Daemon handling the GNOME session settings
  8. gnome-session-ubuntu -> GNOME Session Manager
  9. gnome-control-center-ubuntu -> Utilities to configure the GNOME desktop
  10. gnome-screensaver-ubuntu -> Screensaver and screen locking for GNOME
  11. metacity-ubuntu -> Lightweight GTK+ window manager
  12. gsettings-desktop-schemas-ubuntu -> Shared GSettings schemas for the desktop
  13. gnome-settings-daemon-ubuntu -> Daemon handling the GNOME session settings
  14. gnome-session-ubuntu -> GNOME Session Manager
  15. gnome-control-center-ubuntu -> Utilities to configure the GNOME desktop
  16. network-manager-applet-ubuntu -> Network Manager applet with indicator support
  17. gnome-bluetooth-ubuntu -> Gnome bluetooth applet with indicator support
  18. fixesproto-ubuntu -> X11 Fixes extension wire protocol
  19. libxfixes-ubuntu -> X11 misc. ‘fixes’ extension library
  20. xorg-server-ubuntu -> Xorg X server
  21. nautilus-ubuntu -> File manager and graphics shell for GNOME
  22. compiz-core-ubuntu -> Compiz core components
  23. libcompizconfig-ubuntu -> Compiz configuration system library
  24. compizconfig-backend-gconf-ubuntu -> GConf backend for Compiz
  25. compizconfig-python-ubuntu -> Compizconfig bindings for Python
  26. ccsm-ubuntu -> Compiz configuration manager
  27. compiz-plugins-main-ubuntu -> Compiz main plugins
  28. compiz-plugins-extra-ubuntu -> Compiz extra plugins

Inutile de préciser que cela prend un certain temps, même si on ne compile pas les paquets dédiés à kde ou xfce. La version spécifique de qt, qt-ubuntu prend environ 1 h 15… J’ai commencé à 17 h 33 ce 19 juillet, et l’ensemble des paquets a été terminé vers… 23 h 30… Oui, près de 6 heures pour compiler l’environnement au complet. Et encore, j’ai du rajouter lightdm et son paquet lightdm-gtk-greeter pour le lancer 🙂

Après le premier lancement, j’ai rajouter quelques outils de gnome, ainsi que Mozilla Firefox, LibreOffice ou encore Gwibber.

Une petite vidéo pour montrer l’ensemble en action. C’est loin d’être parfait, surtout que je suis resté aussi basique que possible, spécialement pour Light DM. J’avoue aussi que l’ergonomie d’Unity me laisse pantois.

Bilan rapide : le code semble avoir été travaillé pour devenir portable, mais c’est au prix d’une longue compilation. Ce qui m’a fait spécialement tiqué, c’est l’obligation de recompiler certains paquets « sensibles » comme le serveur X, alors que tous les autres environnements de bureau et gestionnaire de fenêtres qui existe ne demande aucune recompilation.

Il est aussi dommage que le menu global ne soit pas fonctionnel, à moins que je sois tombé sur une version portée qui souffre d’un bug dans ce domaine.Je terminerais en posant une question : pourquoi la LinuxMint a pris comme base mutter, devenant Muffin, pour gérer l’affichage de son interface Cinnamon ?

Et la même question pour le projet ElementaryOS qui utilise Gala (cf cet article de Devil505), sachant que c’est aussi un dérivé de mutter ?

Pourquoi les deux projets n’ont pas utilisé comme Canonical le code de Compiz ? J’avoue que je n’en ai pas la moindre idée.

e17-svn sur Archlinux ? Mais si, c’est possible ;)

L’arrivée prochaine d’une version stable d’e17 (en développement depuis 1999 !) m’a donné envie de voir l’ensemble sur Archlinux. J’ai donc utilisé une archlinux virtualisée, en utilisant Syslinux comme gestionnaire de démarrage pour éviter un bug avec grub2.

J’ai donc installé une archlinux « basique » avec Xorg. Il y a bien des paquets sur le dépot community d’Archlinux, mais ils sont un peu trop « vieux », datant du mois de mai dernier. J’ai donc utilisé le paquet « arche17 » pour installer l’environnement, qui reste encore assez restreint côté outils.

Ensuite, j’ai suivi l’ordre de compilation suivant des paquets pour éviter de me prendre la tête outre mesure :


eina-svn-arche17 - embryo-svn-arche17 - eet-svn-arche17 - evas-svn-arche17 - ecore-svn-arche17 -edje-svn-arche17 - efreet-svn-arche17 - e_dbus-svn-arche17 - emprint-svn-arche17 - eeze-svn-arche17 - elementary-svn-arche17 - e-svn-arche17 - e-modules-extra-svn-arche17

Pour le réseau ? Connman. Pour une fenêtre de ligne de commande ? Terminology via le paquet terminology-svn

Et pour le gestionnaire de connexion, elsa, outil officiel d’e17 pour cette fonction.

J’ai modifié le fichier /etc/inittab pour démarrer en init5 et en rajoutant la ligne de commande suivante :


x:5:respawn:/usr/sbin/elsa

Continuer la lecture de « e17-svn sur Archlinux ? Mais si, c’est possible 😉 »

Emmabuntus 2 : une distribution GNU/Linux à vocation sociale.

Le 14 juillet 2012, le projet Emmabuntus a sorti une deuxième ISO de son système d’exploitation. Basé sur une Xubuntu 12.04 LTS, l’image ISO que j’ai récupéré via BitTorrent pèse dans les 3 Go.

A l’origine du projet, un coup de gueule de Patrick, bénévole chez Emmaüs, que l’on peut lire sur le Framablog.

Mon compère, le frétillant Cyrille Borne en avait parlé en avril dernier.  Ayant été contacté par un proche du projet, j’ai décidé de faire un article sur cette distribution, dont l’annonce de publication montre déjà la couleur et l’orientation du projet.

L’image est un LiveCD/USB installable de manière classique.

L’installation n’est pas excessivement gourmande, surtout quand on voit la quantité de logiciels proposées. En effet, à peine 4 Go… L’installateur est celui de la famille des Ubuntus, donc du solide et fonctionnel. En 5 minutes, l’ensemble est installé.

Continuer la lecture de « Emmabuntus 2 : une distribution GNU/Linux à vocation sociale. »

L’oiseau du tonnerre a fait couler pas mal d’encre électronique.

Depuis une grosse semaine, un bruit se répand sur la blogosphère libre : la Fondation Mozilla va arrêter le développement de Mozilla Thunderbird… Non seulement, deux développeurs du logiciel, démontent la rumeur, à savoir Ludovic Hirlimann, et Mike Conley mais Tristan Nitot met une nouvelle fois les points sur les i et les barres sur les t

Je me suis abstenu de parler de cette annonce prématurée sur le blog, mais l’une des meilleures réponses que j’ai lu est celle de PostBlue : Thunderbird : pas de nouveauté, pas de chocolat :

Certains libristes s’emballent, lisent vite la nouvelle de la génération mac se faisant une bonne gorge chaude à dire que « chez-eux-c’est-mieux-d’abord », et nous y sommes : Mozilla va arrêter le développement de Thunderbird. D’autres d’ailleurs vont plus loin encore, puisque l’arrêt de Thunderbird enfoncerait la crédibilité de la communauté opensource.
[…]
Pour moi, voir la mort d’un projet à l’arrêt de sa course effrénée aux nouveautés, au profit d’une recherche plus poussée de stabilité et de sécurité est, en soi, quelque chose de drôle. Oui, vraiment : drôle. Allons dire ça à Debian ou à LaTeX, qu’on se marre. Il ne m’étonnerait même pas qu’on en vienne à se se taper sur la cuisse, le rire gras et tonitruant, en pensant à tant de beauf^WAppl^WUbun^Wsuperficialité à l’égard du logiciel. Pas de nouveauté, pas de chocolat, c’est ça ?
[…]
La stabilité et la sécurité d’un logiciel tel qu’un client mail en sont pour moi les deux caractéristiques essentielles, qui ne peuvent pas s’effacer au bénéfice d’un « effet d’annonce » aussi vide que l’éjaculat-pré-release de Firefox. Cette illusion de la nouveauté, parée de tant d’artifices clinquants, m’effraie : peut-on avoir confiance en un projet qui, tous les trois mois et demi, ajoute un bouton ci et là, change un menu mais pas ses fonctions, juste histoire de rester psychologiquement à jour, sans pour autant assumer de se consacrer à la stabilité et à la sécurité de celui-ci ? À mon avis, non.

C’est le genre d’article que j’aurais voulu écrire, mais je pense que les mots auraient été un peu moins diplomatique.

Maintenant qui croire ? Les personnes qui sont au coeur du développement du logiciel ou de sombres magazines partisans ?