gouttegd a écrit 1805 commentaires

Voilà, je cherche donc un moyen de désactiver définivement ce comportement agaçant de firefox, j'ai farfouillé dans about:config (j'ai déjà viré tout ce qui avait trait à google dedans), et regardé tout ce qui concernait le network, mais rien ne concerne vraiment cela, du moins je en trouve pas comment faire.

Normalement, ce comportement est contrôlé dans about:config par les options network.portal-captive-service.* (notamment enabled, qui l’active ou le désactive) et captivedetect.* (notamment canonicalURL, qui donne la ressource à laquelle Firefox tente d’accéder pour déterminer s’il est en présence d’un portail captif).

Sinon, chapeau bas pour être passé à travers l'arrosage de news jusqu'à midi.

Si tu vis hors de France, c’est pas très difficile. Perso, ici en Angleterre, je n’ai rien vu, rien entendu.

C’est d’ailleurs assez frappant de voir à quel point les journaux français ne parlent que de ça alors que les journaux du reste du monde s’en balancent pas mal (ils préfèrent parler de Trump, du Proche-Orient, de la Corée du Nord, du Brexit, ce genre de trucs quoi).

Euh, vu le problème qu’il décrit (un programme dont la fenêtre principale ne s’affiche pas), je ne vois comment un utilisateur lambda est supposé trouver quelque chose d’utile là-dedans. En tout cas ce n’est certainement pas ce à quoi je m’attendrais pour un système dont on vante sans arrêt l’user-friendliness.

Enverrait-on un utilisateur Windows qui rencontrerait un problème similaire vers la documentation de CreateWindowEx dans l’API Win32 ? Ou un utilisateur de GNU/Linux vers la documentation correspondante de X.org ?

il y a toujours eu des soucis.

J’ai travaillé pendant des années dans un environnement où presque tout le monde autour de moi utilisaient Mac OS X. J’utilise moi-même Mac OS X dans mon environnement professionnel actuel (le service IT m’a refusé la possibilité d’utiliser un système GNU/Linux, et ne m’a laissé le choix qu’entre Windows et Mac OS X).

Et bien ce que je peux dire, c’est que je suis désormais convaincu que la réputation de qualité et d’infaillibilité des Mac vient principalement de leur rareté. Quand il y a un Mac OS X pour 10 Windows, forcément on a l’impression que chaque fois qu’il y a un problème comme par hasard ça touche une machine Windows, et donc que le Mac doit être intrinsèquement « mieux ».

Mais quand il n’y a presque que des Mac, et ben on se rend compte que non, ils n’échappent pas à leur lot de problèmes. Plantages, ralentissements inexpliqués, montages réseaux qui marchent une fois sur deux, comportements incohérents de l’interface… « il y a toujours eu des soucis »

(Et que les fanboys Apple ne viennent pas me dire que ce sont des histoires de Linuxien aigri — dans mon précédent labo c’était vers moi qu’on se tournait chaque fois qu’il y avait un problème, alors je suis bien placé pour savoir que des problèmes il y en avait.)

’tin le cliché du Linuxien qui déteste Windows tandis que le BSDiste aime le libre, ça faisait longtemps que je ne l’avais pas entendu, je pensais qu’on avait dépassé ça…

oui bon, si le disque système est chiffré, en effet, ça commence à devenir compliqué… ça existe ça ?

Un peu, oui !

Je dirais même que c’est un must-have de nos jours, a fortiori sur un ordinateur portable. Ça évite de se retrouver avec des données sensibles dans la nature suite à un vol de portable…

Tous les systèmes modernes proposent le chiffrement du disque dur à l’installation.

Comment ça boote alors ? Demande de mot de passe systématique lors du boot ?

Ça, ou d’autres méthodes comme par exemple avoir la clé de (dé)chiffrement sur une clef USB qui doit être présente lors du démarrage. On peut imaginer encore plus raffiné, comme déverrouiller le disque dur avec une smartcard.

Comme quoi c’est bien vrai que Mac OS X est plus user-friendly que GNU/Linux — sous GNU/Linux, il fallait taper la touche backspace 27 fois d’affilée pour bypasser la sécurité, là où Mac OS X permet d’arriver au même résultat en frappant simplement la touche Entrée…

Se soucier d’être facile d’utilisation jusque dans les bugs critiques, c’est beau.

(Plus sérieusement, comme le lien fourni dans le journal ne concerne pas directement le bug — c’est juste la procédure à suivre pour activer un compte root, ce qui est une manière de rendre le bug inexploitable —, voici plus d’infos.)

c'est que dans un pays comme le Japon, ils arrivent à faire en sorte que leurs trains soient à l'heure

En Angleterre, ce n’est pas mal non plus, même s’ils n’en sont pas au point de s’excuser lorsqu’un de leurs trains part 20 secondes en avance.

Pour moi c'est juste une question de mentalité et de volonté

Je pense qu’une des raisons est simplement que les Anglais dépendent beaucoup plus du train que les Français, et utilisent leur réseau de façon beaucoup plus intensive.

En France, tous les TER que j’ai eu l’occasion d’utiliser circulaient au maximum à raison d’un train par heure, et je connais même une ligne qui ne voit passer que deux trains par jour. Et la moitié des gares sur le chemin ne sont même plus desservies. On a largement laissé tomber le train en France, il me semble.

De l’autre côté de la Manche, même dans une petite gare paumée les trains régionaux se succèdent à raison d’au moins un tous les quarts d’heure…

Rien de très complet, juste un hobby que je fais à mes heures creuses…

Fais gaffe, la dernière fois que quelqu’un a dit un truc similaire, c’est parti en cacahuète très vite, ça fait bientôt trente ans que le type travaille sur son « juste un hobby »…

Je ne sais pour Systemd, mais pour NetworkManager, on peut lui demander gentiment de ne pas toucher à /etc/resolv.conf en ajoutant :

[main]
dns=none

dans son fichier de configuration (/etc/NetworkManager/NetworkManager.conf ou assimilé). Ça signifie en gros « Merci de ne pas toucher à ma config DNS, je m’en occupe moi-même. »

C’est (malheureusement) assez fréquent. Troy Hunt (le développeur derrière haveibeenpwned.com) a répertorié quelques exemples.

Le problème n'est pas ton téléphone, pas d'urgence pour lui, plutôt l'idée que quelqu'un utilise ta connexion Internet perso. Enfin, si j'ai bien compris, corrigez moi si j'ai loupé un épisode.

Hum, non, si j’ai bien compris, la faille présentée (même dans sa pire version, celle qui affecte wpa_supplicant et donc les téléphones Android ≥ 6) ne permet pas à un tiers d’utiliser ta connexion.

Elle lui permet (potentiellement) de déchiffrer tout ou partie du traffic, et d’injecter ses propres paquets fabriqués dans le traffic (ouvrant probablement la porte à toutes sortes d’attaques — je pense par exemple à tous ces sites dont la page de connexion est envoyée en clair, et qui ne passent en https qu’après l’authentification de l’utilisateur :facepalm: ), mais pas de s’authentifier comme un utilisateur légitime du réseau WiFi sur lequel l’attaque a lieu.

C’est notamment pour ça que les auteurs ne recommandent pas de changer les mots de passe des points d’accès, parce que c’est inutile — ils ne sont pas compromis par cette faille.

Le principal, peut-être le seul, problème que j’ai avec ma liseuse, c’est l’impossibilité (en pratique) de « feuilletter » un livre. La seule navigation confortable à l’usage est d’aller à la page suivante (ou précédente) ; tout déplacement à l’intérieur d’un livre qui ne se résume pas à un simple « tourner une page » est trop pénible en pratique.

Or avec un livre papier, c’est le genre de choses que je fais régulièrement. Par exemple, quand je reprends le livre après l’avoir laissé un jour ou deux, j’aime bien reprendre ma lecture non pas là où je l’avais arrêtée, mais quatre ou cinq pages en arrière. Quand l’heure approche de reposer le livre, j’aime bien regarder quatre ou cinq pages en avance pour voir si la fin du chapitre est proche.

À n’importe quel moment pendant la lecture, j’ai aussi parfois envie de revenir une dizaine, une trentaine, ou une centaine de pages en arrière pour relire un passage — dont je ne me souviens pas de la page exacte, mais dont je sais à peu près où il se trouve. C’est cet « à peu près » qui pose problème : avec un livre papier, je peux parcourir les pages et retrouver en général très rapidement le passage qui m’intéresse. C’est impossible avec une liseuse (du moins avec la mienne).

À côté de ça, j’apprécie quand même beaucoup le côté « toute ma bibliothèque tient dans ma poche ». Et je n’ai jamais lu autant de « classiques » que depuis que j’ai ma liseuse et que j’ai découvert le projet Gutenberg.

pourquoi wpa_supplicant est-il le pire?

Si j’ai bien compris :

Parce que lorsqu’il reçoit le 3ème message de la poignée de main (le message qui établit la clef de chiffrement) plusieurs fois de suite, wpa_supplicant ré-initialise la clef de chiffrement à zéro, ce qui rend le déchiffrement du traffic ultérieur trivial.

Les autres implémentations laissent la clef inchangée, mais avec un nonce prévisible, ce qui rend possible des tentatives de déchiffrement sur le traffic ultérieure, mais pas de manière aussi triviale que dans le cas précédent.

Le comportement de wpa_supplicant est apparemment le résultat d’une ambiguïté dans le standard (“This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time.”).

En même temps 1 mois c'est déjà extremement long pour ce type de failles.

Ça ne me paraît pas déraisonnable pour une faille qui affecte de multiples projets et éditeurs.

En 2008, l’embargo autour de la « faille Kaminsky » dans les implémentations DNS avait été beaucoup plus long (si je me souviens bien, au moins de mars à août).

Ici OpenBSD n'y est pour rien !
[…]
C'est lui qui a autorisé OpenBSD à faire la correction en avance.

Après que Theo de Raadt s’est plaint. Et au final, OpenBSD a gagné quoi dans l’histoire ?

M. Vanhoef: On va annoncer d’ici six semaines une vulnérabilité critique. [Détails de la vulnérabilité, et proposition de fix.] Ne publiez pas le fix tout de suite SVP.

T. de Raadt: C’est très décourageant de nous demander d’attendre un mois avant de publier un correctif !

M. Vanhoef: Bon OK, désormais on vous préviendra après tous les autres, quelques jours seulement avant de rendre la vulnérabilité publique, comme ça vous n’aurez pas à attendre longtemps.

Alors, ça ne me concerne (pour l’instant) plus car aucun des réseaux auxquels je connecte mon PC n’a de proxy, mais j’ai été dans cette situation il y a quelques années, et je procédais ainsi.

D’abord, un script lancé par NetworkManager se charge d’identifier le réseau auquel je viens de me connecter. Il utilise pour ça toute information disponible dans la réponse DHCP du réseau permettant d’identifier de manière unique un réseau donné (l’idéal est la variable DHCP4_DOMAIN_NAME, mais tous les serveurs DHCP ne fournissent pas cette information). Une fois le réseau identifié, il écrit un nom arbitraire pour ce réseau dans le fichier /var/state/network.

#!/bin/sh

interface=$1
status=$2

case "$status" in
up)
    if [ "x$DHCP4_DOMAIN_NAME" = 'xschool.example' ]; then
        echo school > /var/state/network
    elif [ "x$DHCP4_DOMAIN_NAME" = 'xcompany.example' ]; then
        echo company > /var/state/network
    elif [ "x$IP4_NAMESERVERS" = 'x203.0.113.65' ]; then
        # Cas d'un réseau qui ne fournit que très peu d'infos,
        # on se base sur l'adresse du serveur DNS indiqué dans
        # la réponse DHCP -- en espérant qu'elle ne change pas
        # au cours du temps...
        echo discret > /var/state/network
    else
        echo unknown > /var/state/network
        # On dumpe toutes les variables dans un fichier,
        # dans l'espoir d'y trouver des infos qui permettront
        # de mieux caractériser ce réseau inconnu
        env > /var/state/network.infos
    fi
    ;;

esac

Le contenu du fichier /var/state/network peut ensuite être utilisé par d’autres scripts pour toutes les actions qui doivent varier en fonction du réseau. En particulier, un script se charge d’écrire les informations relatives aux proxys dans un fichier /etc/proxy.conf :

#!/bin/sh

[ "x$2" = xup ] || exit 0

case "$(< /var/state/network)" in
school)
    echo PROXY_ON=1 > /etc/proxy.conf
    echo PROXY_HOST=www-cache.school.example >> /etc/proxy.conf
    echo PROXY_PORT=3128 >> /etc/proxy.conf
    echo EXCEPTIONS=.school.example >> /etc/proxy.conf
    ;;

company)
    echo PROXY_ON=1 > /etc/proxy.conf
    echo PROXY_HOST=cache.company.example >> /etc/proxy.conf
    echo PROXY_PORT=3128 >> /etc/proxy.conf
    echo EXCEPTIONS= >> /etc/proxy.conf
    ;;

*)
    # No proxy on the other networks
    cat /dev/null > /etc/proxy.conf
    ;;

esac

À ce stade, on se retrouve avec un fichier /etc/proxy.conf qui contient les informations sur le proxy à utiliser. Le reste est l’affaire d’un script exécuté au démarrage d’une session (par exemple dans ~/.xprofile), qui doit lire ce fichier et s’assurer que tous les programmes tiennent compte du proxy. C’était la partie la plus délicate car tous les programmes n’ont pas le bon goût de respecter la variable d’environnement http_proxy … Je n’ai plus ce script sous la main, mais de mémoire il faisait à peu près ça :

• définir http_proxy et no_proxy pour les programmes bien élevés ;
• éditer le fichier de configuration KDE définissant le proxy pour toutes les applications KDE (je ne sais plus quel était ce fichier, mais de toute façon depuis le temps ça a peut-être changé) ;
• éditer le fichier .mozilla/firefox/{profile}/prefs.js pour Firefox (qui à une époque n’était pas un programme bien élevé) ;
• définir un alias java=java -Dhttp.proxyHost=proxy_host -Dhttp.proxyPort=proxy_port pour les programmes Java ;
• et peut-être encore deux ou trois autres cas particuliers.

Globalement, ce n’était sûrement pas une solution parfaite, mais ça marchait quand même à peu près bien (mis à part le fait que le passage d’un réseau à un autre n’était pas pris en compte immédiatement, il fallait redémarrer la session graphique pour que le script .xprofile relise /etc/proxy.conf et que l’environnement soit mis à jour — mais comme il ne m’arrivait que rarement de changer de réseau pendant une session, ce n’était pas très gênant).

A quand un projet d'IHM à la "wahhoouu effect" ?

C’est pas déjà ce qu’on a tenté de faire il y a quelques années ? Avec des trucs comme « Compiz » ou quelque chose dans le genre ? Le cube 3D, les fenêtres qui s’embrasent au moment de les fermer, etc.

C’est passé de mode, non ?

s'assurer que notre bibliothèque SSH marche correctement sur toutes les plateformes. Oui, j'ai écrit une bibliothèque SSH, c'est l'un des inconvénients de travailler avec un langage trop jeune.

Et déléguer tout ça à OpenSSH (comme le fait Git, sous GNU/Linux du moins), ce n’était pas envisageable ?

Un programme qui vient avec sa propre implémentation de SSH, c’est un programme ui dans 99% des cas :

• ignore le contenu de ~/.ssh/config,
• ou essaie de prendre en compte ce fichier mais n’en gère pas toutes les subtilités (ProxyCommand par exemple),
• ne sait pas utiliser un agent SSH.

Rien que le dernier point rend un tel programme inutilisable pour moi, ma clef privée étant stockée sur une carte à puce rendant l’utilisation d’un agent indispensable.

J’admets ne pas lire le Rust couramment, mais je ne vois rien dans le code de thrussh ou de pijul lui-même qui me laisse penser que le protocole SSH-Agent est pris en charge.

On parle parfois de Shared Source, surtout pour quand il s’agit de Microsoft et de sa Reference Source License (qui donne le droit « d’utiliser le logiciel [distribué sous cette licence] comme référence, en lecture seule, dans le seul but d’aider au débogage et à la maintenance de vos produits, ou d’améliorer l’intéropérabilité de vos produits avec le logiciel » et interdit explicitement de « distribuer le logiciel en-dehors de votre société » — traduction libre).

Il me semble (de mémoire) que quand je rajoute une CA dans /usr/local/share/ca-certificates et que je fais update-ca-certificates firefox/iceweasel reconnaît la nouvelle CA

Ce n’est définitivement pas le cas par défaut chez moi. Ça n’est le cas en pratique que parce que j’ai forcé Firefox à utiliser libp11-kit.so (qui va chercher les certificats dans /etc/ssl/certs) au lieu de sa propre bibliothèque libnssckbi.so (qui contient les certificats directement, ils sont inclus « en dur » à la compilation). Il suffit pour ça de supprimer libnssckbi.so et de la remplacer par un lien symbolique vers libp11-kit.so.

Après peut-être que certaines distributions font ce remplacement d’office, je ne sais pas.

Je croyais que c'était aussi le cas sous Windows

J’étais persuadé que non, mais apparemment je me trompais. Autant pour moi.

Effectivement il semble que Firefox utilise ses propres certificats quel que soit le système, pas seulement sous GNU/Linux.

Si oui, ne serait-il pas plus pertinent d'avoir un ou plusieurs paquets séparés pour les certificats

C’est déjà le cas, au moins sur certaines distributions. Debian a un paquet ca-certificates contenant les certificats racines, de même que Slackware¹. Je ne serais pas étonné que d’autres distributions fassent la même chose.

En pratique ce paquet ne contient pour l’instant que les certificats des racines reconnues par Mozilla, mais en théorie il pourrait contenir des certificats provenant d’autres sources (à une époque il contenait par exemple le certificat racine de CAcert).

ça permettrait à l'administrateur d'avoir un contrôle plus aisé de à qui faire confiance

C’est le but du paquet ca-certificates. Il installes les certificats non pas directement dans /etc/ssl/certs, mais dans /usr/share/ca-certificates, et il fournit l’outil update-ca-certificates(8) pour créer des liens symboliques dans /etc/ssl/certs (l’administrateur ayant la possibilité de « désactiver » les racines dont il ne veut pas dans /etc/ca-certificates.conf, et d’ajouter des racines supplémentaires dans /usr/local/share/ca-certificates).

À noter tout de même que ce paquet n’est absolument pas utilisé par Firefox, qui utilise toujours ses propres certificats (directement inclus dans la bibliothèque libnssckbi.so), indépendamment du contenu de /etc/ssl/certs. C’est à ma connaissance une spécificité de la version GNU/Linux de Firefox, les versions Windows et OS X utilisent il me semble le magasin de certificats du système.

On peut forcer Firefox à utiliser les certificats de /etc/ssl/certs en remplaçant sa bibliothèque libnssckbi.so par la bibliothèque libp11-kit.so du projet p11-glue.

---

¹ En fait Slackware ré-utilise directement le paquet de Debian, parce que ouais bon, Debian rules! (mais il ne faut pas le dire trop fort :D ).

mais ce n'est pas le cas de la plupart des bibliothèques que l'on trouve partout.

Pour ce que ça vaut, sur 80 modules Python que j’ai installé moi-même, j’en compte 35 qui comportent une partie compilée en bibliothèque ELF.

Ce n’est peut-être pas « la plupart », mais ce n’est pas rare non plus.

Hum. C’est récent cette fonctionnalité ?

Euh, non. Je ne sais pas quand ça a été introduit ou même si ça a toujours été possible, mais j’utilise plusieurs profils simultanément depuis au moins 2010.