Debian Jessie permet de choisir son environnement de bureau à l’ installation

L’installeur de la prochaine Debian (8) permet de choisir choisir son environnement de bureau dès l’étape d’ installation.

Cela permet de beaucoup simplifier l’installation de Debian avec son environnement préféré. Sur Debian 7, il faut installer l’environnement de bureau par défaut, installer l’environnement de bureau désiré, puis désinstaller l’environnement de bureau par défaut. Cela est un frein pour les débutants et inutilement compliqué.

Cela permet aussi de limiter le besoin de fragmentation de la distribution comme ce qu’on voit avec Ubuntu (Gnome), Xubuntu (XFCE), Kubuntu (KDE), Lubuntu (LXDE), etc…

Les environnements de bureau proposés à l’installation sont :

  • Gnome
  • Xfce
  • KDE
  • Cinnamon
  • MATE
  • LXDE

jessie1

J'aime(13)Ferme-la !(0)

Steam sur Debian Jessie : OpenGL GLX context is not using direct rendering

Si en lançant Steam, vous avez un message d’erreur du type :

Error: OpenGL GLX context is not using direct rendering, which may cause performance problems.
For more information visit https://support.steampowered.com/kb_article.php?ref=9938-EYZB-7457.

Vérifiez d’abord que vous avez le « Direct rendering » actif par la commande suivante :
$ glxinfo | grep direct

Si non, il s’agit d’un problème de driver graphique (mal installé, carte graphique non supportée…)
Si oui, il se peut que ce soit simplement votre driver qui demande une librairie C plus récente que celle fournie par Steam. Donc pour forcer Steam à utiliser la librairie C de votre système :
$ locate stdc++ | grep steam | xargs rm

Et voila !

J'aime(0)Ferme-la !(0)

Debian 8 Jessie sera livrée avec le noyau Linux 3.16

Récemment, les développeurs de Debian et d’autres intervenants ont essayé de choisir quel noyau embarquer dans Debain 8 Jessie:

  • le noyau actuel, 3.14, qui est la dernière version stable du noyau LTS de Greg KH et a donc un bon support pendant 2 ans (jusqu’à mars 2016)
  • le noyau Linux 3.16 qui apporte un meilleur support du matériel récent et qui destiné à être utilisé par Ubuntu 14.10. L’équipe du noyau de Canonical/Ubuntu devrait apporter son support pendant 2 ans (jusqu’en octobre 2016.)

Finalement, par la voix de Ben Hutchings sur la mailing list debian-kernel, il semble que la prochaine version majeure de Debian 8 Jessie sera livrée avec le noyau Linux 3.16

J'aime(9)Ferme-la !(0)

Mysearch 1.4 : cachez votre IP avec le mode relai

MySearch est un programme qui va récupérer les résultats de recherches sur Google, GoogleImage, Wikipedia, Openstreetmap, ou Yacy et les afficher en enlevant tout ce qui utilisé pour vous tracer : cookies personnels, liens personnalisés, javascript traceur, images traceuses, etc…

Par exemple, voici mon instance perso : http://search.jesuislibre.net

Vous allez me dire, ca ressemble à DuckDuckGo, mais sans les bangs. Mais DuckDuckGo n’a pas la pertinence de Google. MySearch, oui.
Et comment être sûr que DuckDuckGo ou Mysearch ne m’espionnent pas aussi? Avec Mysearch, vous avez accès au code source, et surtout vous pouvez l’installer facilement sur votre machine grâce au paquet Debian (nécessite Debian Jessie).
Une fois installé, vous pouvez y accéder par http://localhost:60061

Il restait un problème, si j’installe Mysearch sur ma machine, alors Google aura connaissance de mon IP et pourra toujours lier mes mots clés à mon IP. C’est là qu’intervient le mode relai entre installations Mysearch !

C’est encore en beta/alpha mais l’idée est que votre recherche soit transmise par l’intermédiaire d’une autre installation Mysearch plutôt qu’en direct. Rassurez-vous, cet intermédiaire ne pourra pas connaître les mots clés que vous cherchez ni connaître ou altérer les résultats car le flux est chiffré par SSL de bout en bout.

Pour activer le mode « relai »:
Modifiez le fichier de config /etc/mysearch/mysearch.conf mettez la valeur relay = true
Pour prendre en compte le changement, relancez le service : #service mysearch restart
Le port 60062 est utilisé pour le relai et doit donc être ouvert.

En activant le mode relai :
– Toutes les requêtes que vous lancerez devront passer par un intermédiaire sinon elles échoueront. Pour l’instant, l’intermédiaire est forcé à search.jesuislibre.net. Si les requetes ne marchent plus vérifier que mon serveur est toujours en ligne ;-) Si le service est utilisé, j’organiserai une pool.
– Vous autorisez automatiquement les autres à pouvoir utiliser votre relai pour leurs requêtes. Vous pouvez vérifier si votre relai est utilisé par d’autres en regardant sur la première page. Normalement vous ne devrez pas voir de connexions étant donné que le pooling n’est pas actif pour l’instant.

mysearch

J'aime(7)Ferme-la !(0)

L’accélération 3D des cartes ATI radeon 7xxx avec le driver libre arrive dans Debian

Aujourd’hui, une mise à jour de xserver-xorg-core est arrivée dans Debian Testing.

Celle-ci active GLAMOR et par conséquence le support de l’accélération 3D pour les cartes ATI Southern Island (ATI Radeon 7750 et plus) dans les drivers libres radeon !

C’est donc avec une certaine joie que j’ai pu voir Blender, HoN, The Witcher2, Dota 2 enfin fonctionner sans le driver propriétaire Catalyst qui traine de vieux bugs. Ma carte étant de 2012, il était temps !

Ca fonctionne « out of the box ». Il n’y a pas de fichier de config à renseigner. Pour vérifier, lancez cette commande : $ glxinfo | grep OpenGL

Vous devriez voir ceci :

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:

Seul hic, certains logiciels tels que Steam et HoN embarquent leur propres librairies GCC et là ca ne marche pas du premier coup. Vous verrez apparaître un message du style :

Error: OpenGL GLX context is not using direct rendering, which may cause performance problems.

Pour régler cela il faut supprimer les vieilles librairies libgcc et libstdc++ embarquées avec HoN ou Steam, ce qui forcera l’utilisation des librairies de votre système Debian à la place :

$ locate -e libgcc | grep « steam\|HoN » | xargs rm
$ locate -e libstdc++ | grep « steam\|HoN » | xargs rm

J'aime(4)Ferme-la !(0)

OpenSSL et la vérification du domaine dans les certificats

Je suis en train de rajouter de l’onion routing à mon moteur de recherche MySearch. Je me suis donc penché sur comment Twisted (13.2) gérait les connexions SSL.

Tout d’abord, il faut savoir qu’une connexion web HTTPS dans Twisted ne fait aucune vérification de certificat par défaut. C’est écrit dans la doc et dans l’API.

Enfin « par défaut », il faut comprendre « sans mettre les mains dans le cambouis ». Car quand on regarde plus en profondeur dans le code de Twisted, on voit que les connexions SSL reposent sur PyOpenSSL , qui est comme vous vous en doutez un binding pour la fameuse librairie OpenSSL.

Dans Twisted, voici ce qu’on trouve de plus exhaustif pour vérifier la sécurité de sa connexion SSL. Là, le premier truc qui choque, c’est que le hostname de destination n’apparaît pas dans le code de vérification des certificats.

On se dit qu’on loupe quelque chose, on va voir du coté de la doc de PyOpenSSL . Pareil, pas de fonction qui vérifie la correspondance du hostname demandé avec le certificat présenté. Et pas un mot sur le sujet.

Allons donc voir ce qu’en dit OpenSSL. Et là c’est beau, je vous le donne en mille :

One very common mistake made by users of OpenSSL is to assume that OpenSSL will validate the hostname in the server’s certificate. Currently, it does not, although a future version (1.1.0?) will include this functionality.

C’est écrit noir sur blanc et .

Sérieusement, vous pensez qu’il est sain de forcer des programmeurs lambda à coder une fonction si critique qui va vérifier le hostname de destination avec toutes les règles de subject alt name encodées en ASN.1 sans faire le moindre faux positif ni faux négatif ?

Je serai amusé de voir le code de cette partie de quelques applications reposant sur OpenSSL. On risque de trouver des manières élégantes de faire du MITM avec un simple certificat adapté…

Par pur hasard, une nouvelle version de Twisted (14.0) est sortie ces jours-ci. Les notes de mise à jour indiquent de grandes améliorations autour des communications SSL (enfin dirais-je !).

Je vais donc, curieux, voir comment ils se sont sorti de ce piège. Le code de vérification du hostname est en fait externalisé à un module Python externe : service_identity , module créé en mars 2014 (semble t il par des codeurs de Twisted). Ca c’est du code sûr, vérifié et testé… qui prend quand même environ 430 lignes de Python (avec beaucoup de lignes blanches je vous l’accorde).

Voici d’autres exemples du joli cadeau sue nous lègue OpenSSL :

 

J'aime(0)Ferme-la !(0)

Avoir le verr Num. actif par défaut sous Gnome 3

Un truc bien chiant est de devoir activer le pavé numérique à chaque fois que l’on démarre une session Gnome.

Depuis Gnome 3 il est possible de demander à ce que le réglage de l’état du pavé numérique soit conservé entre les sessions. Enfin !
Ca s’active ainsi en ligne de commande:

$ gsettings set org.gnome.settings-daemon.peripherals.keyboard remember-numlock-state true

Ou graphiquement en démarrant dconf-editor et en allant chercher la clé org.gnome.settings-daemon.peripherals.keyboard remember-numlock-state

J'aime(6)Ferme-la !(0)

USB dumper

Je vous avais déjà parlé des risques de brancher un téléphone Android par USB pour le recharger. En effet, dans le cas où le téléphone est déverrouillé lorsqu’il est branché, l’accès à l’espace de stockage du téléphone est aussi débloqué.

Bref si vous avez des données confidentielles sur votre téléphone, vous devriez, au même titre qu’une clé USB, ne pas le brancher n’importe où.

Pour aller plus loin dans la réflexion, j’ai codé un programme qui démontre comment vos données pouraient aisément être copiées sans que vous vous en aperceviez.
Ce programme s’appelle « usb-dumper« . Une fois lancé, il copie intégralement et silencieusement le contenu de tous les périphériques USB connectés utilisant le mode UMS (clés USB, Android 3.x, appareils photos) ou MTP (Android 4.x, lecteurs audio, appareils photos, etc…) vers le disque dur de votre ordinateur.

Dès qu’un nouveau périphérique USB est connecté, celui est copié. Vous verrez que la procédure est très rapide avec les débits en USB atteints aujourd’hui et que l’on peut se faire subtiliser des GigaOctets en quelques secondes et donc sans s’en rendre compte.

Le code utilise udev pour détecter le branchement de nouveau périphérique et GVFS pour l’accès aux données. L’utilisation de GVFS implique l’usage de Gnome mais c’est le seul moyen vraiment fiable d’accéder à l’espace de stockage des périphérique MTP (Android 4.x) que j’ai trouvé.

Vu que je commence à mieux appréhender la construction de paquet Debian pour mes programmes Python, je vous ai concocté un paquet .deb pour vous faciliter la tâche d’installation.
Lancez « usb-dumper » et branchez un périphérique :-)

Les préférences se trouvent dans le fichier ~/.config/usb-dumper/usb-dumper.conf
Vous pouvez y déterminer les périphériques et les fichiers à ne pas copier ainsi que l’emplacement où seront copiés les fichiers.

Le code source est sous licence libre AGPL et disponible sur la forge CodingTeam.

J'aime(0)Ferme-la !(0)