Il y a environ un an, j’ai pris un compte mail “pro” chez OVH parce que gérer un serveur mail sur mon dédié, c’est vraiment trop prise de tête.

Dans l’ensemble ça fait le boulot. Leur webmail à base d’Outlook est une bouse (pire encore que Gmail, c’est dire) mais comme je n’utilise environ jamais de webmail ce n’est pas vraiment un problème.

J’ai pu avec un seul compte mail déclarer un certain nombre d’alias sur mes différents domaines sans problèmes majeurs.

Enfin à part deux « subtilités » qui m’ont fait perdre énormément de temps sans que je trouve quoique ce soit sur le net qui me mette sur la voie…

Mots de passe : attention aux accents !

J’ai galéré des heures à essayer de me connecter dessus avec Thunderbird sur mon PC et deux clients mails différents sur Android et pas moyen : le seul qui marchait, c’était IMAP sur Thunderbird, IMAP sur Android, pas moyen et SMTP sur aucun des deux.

J’ai tenté plein de trucs, suivi 12 fois toutes les docs, etc. Jusqu’au moment où je me dis que je vais tenter de virer le « é » que j’avais mis dans mon mot de passe pour ajouter un caractère spécial. Et c’était ça : tout marche maintenant. J’ai dû perdre en tout 4 ou 5 heures parce que j’ai mis un accent dans mon mot de passe.

Je ne suis pas près de recommencer, quel que soit le site ou service.

Je précise que je saisissais bien l’accent hein (je passais par copié/collé sur le PC donc pas de faute de frappe). C’est juste que de l’autre côté, il me le rejetait. Puis j’ai viré l’accent et là tout marche.

Pas merci OVH. Mais alors pas du tout.

Alias automatiques en utilisant un « + »

Comme sur d’autres services (comme Gmail, par exemple), on peut utiliser des variantes de l’adresse en ajoutant « + » et une chaîne quelconque à la suite du nom d’utilisateur.

J’utilise ce mécanisme pour fournir un e-mail unique à chaque nouveau site ou service à qui je communique une adresse e-mail, histoire de pouvoir tracer d’où viennent les spams.

Par exemple si l’adresse e-mail est mail@toto.fr, on peut utiliser mail+amazon758@toto.fr, ça marchera également.

Enfin à peu près.

En fait on peut sans problème recevoir un mail via cette adresse-là, il n’y a rien de particulier à faire.

Par contre, pour en envoyer là il faut aller déclarer explicitement un alias dans l’interface de gestion fournie par OVH, sans quoi l’envoi est rejeté.

Voilà voilà, je laisse ça là, sait-on jamais, ça peut servir à quelqu’un d’autre…

La semaine passée, les utilisateurs de Firefox ont dû faire face à une désactivation de l’ensemble des extensions du navigateur (enfin presque, chez moi 5 sont restées, allez savoir pourquoi). Mozilla a fourni rapidement des solutions de contournement et travaillé à résoudre le problème (plus de détails ici) et je n’ai rien à redire là-dessus.

Par contre, ça révèle selon moi un gros problème de fond.

Je ne vais pas m’étendre sur la partie concernant le mécanisme d’« études » dont j’avais oublié l’existence et qui était finalement le seul moyen de contournement trouvé sur un Firefox standard : ce mécanisme permet à Mozilla d’installer silencieusement des trucs sur le navigateur et est fort heureusement désactivé par défaut… même si ça laisse songeur sur les potentielles failles de sécurité ouvertes par ce canal.

Non, ce qui me pose vraiment problème, c’est cette gestion de la signature des modules. Non pas que le fait de signer les modules soit un problème en soi. C’est une réponse tout à fait valable à des attaques via des extensions malveillantes. Mais plutôt la manière dont c’est mis en œuvre.

En effet, cet épisode révèle que :

• la vérification de la signature des modules est désactivable sur environ toutes les versions sauf la version grand public (donc sur ESR, Developer edition, Nightly) via la clé xpinstall.signatures.required (et extensions.langpacks.signatures.require pour les paquetages linguistiques), cf la documentation pour plus d’informations
• les signatures des modules sont revérifiées une fois par jour (cf l’article technique évoqué plus haut) et si la vérification échoue, l’extension est désactivée d’autorité (et silencieusement je crois bien, mais je ne suis plus certain de ce point, il y avait peut-être un petit message dans un coin)

Ces deux points sont pour moi hautement problématiques pour des raisons plutôt bien résumées dans les pouets suivants :

Sinon imaginez Linux avec le même genre de conception ?

Le certificat du dépôt expire, et tous les paquets sont invalidés et votre OS cesse de fonctionner ?

C'est pas juste une bourde, c'est une énorme connerie dès la conception. Une énorme FBI (Fausse Bonne Idée).

Mais c'est pour notre bien, c'est pour notre sécurité. Meh.

Non la pillule n'arrive pas à passer.

— sebsauvage (@sebsauvage@framapiaf.org) le 10 mai 2019 à 19:46

Le problème, c'est que Mozilla commence à faire comme Google : faire les choix à la place de l'utilisateur "pour son bien", non seulement en ne lui proposant pas de choisir, mais en allant jusqu'à rendre la désactivation de l'option IMPOSSIBLE.

À partir de quand c'est une bonne idée ?

Comme on peut considérer ça comme respectueux de l'utilisateur ?

— sebsauvage (@sebsauvage@framapiaf.org) le 10 mai 2019 à 20:12

Que les options par défaut protègent l'utilisateur OK, mais pourquoi empêcher les utilisateurs avancés de modifier l'option ?

— sebsauvage (@sebsauvage@framapiaf.org) le 10 mai 2019 à 20:41

On est là au cœur du problème : Mozilla a mis en place un système de signature des extensions pour protéger contre les extensions malveillantes (et c’est très bien) mais de telle manière que l’utilisateur n’ait aucune manière de contourner le système s’il le souhaite. Mozilla décide et l’utilisateur subit “pour son bien”.

Dans les versions du logiciel destinées à un public technique ou professionnel on permet de désactiver le système, mais pour le grand public, non. Quand je dis que c’est désactivable, on parle bien d’une configuration perdue dans about:config, donc un truc que l’utilisateur lambda n’a aucune chance de toucher par erreur (puisque les extensions ne le peuvent plus). Un truc déjà réservé à des utilisateurs avancés (ceux qui ont passé le message anxiogène et fait l’effort de trouver la clé à modifier). Donc pourquoi l’interdire sur la version grand public ?

Message anxiogène avant d'accéder à `about:config`

Le second point relève de la même logique : on valide tous les jours et en cas d’échec on désactive. Sur le papier ça peut se tenir comme comportement par défaut, mais une fois de plus c’est décider à la place de l’utilisateur.

Comment on peut considérer que faire tout d’autorité sans à aucun moment donner la main à l’utilisateur peut être une bonne idée ? Parce que virer les extensions ça veut dire casser des fonctionnalités (ce qui peut être un gros problème) mais surtout se balader à poil (vu le peu d’outils natifs de protection contre les traqueurs).

Le minimum aurait été de proposer un bouton permettant de réactiver l’extension (après moult messages anxiogènes si on veut) mais un truc qui permette de continuer à utiliser convenablement son navigateur même si un truc s’est mal passé.

Pour moi tout ça est assez symptomatique de la dérive de Mozilla ces dernières années qui se comporte de plus en plus comme un Google ou un Apple : je sais mieux que vous ce qu’il faut faire donc pour votre sécurité je vais décider à votre place.

Je suis désolé, mais pour moi, c’est très loin de l’idéal des logiciels libres. Mais vraiment très loin. C’est infantiliser l’utilisateur en lui déniant le droit de faire des choix (certes il peut toujours patcher son navigateur et le recompiler, hein, mais outre le fait que ça nécessite déjà un gros bagage technique, avec la mode des cycles de développement courts, c’est devenu excessivement laborieux).

Encore une fois, je ne dis pas qu’il faut laisser faire les pires conneries en deux clics, mais juste laisser des solutions de contournement, a fortiori quand elles existent (puisque la clé de configuration existe dans les autres versions, ça n’introduirait même pas de coût de maintenance supplémentaire).

Tout ça me renforce dans mon impression de plus en plus forte que Mozilla tend à s’apparenter à un Parti Socialiste du logiciel : on fait valoir de grands idéaux, mais finalement on va au même endroit que les autres, juste un peu plus lentement. Et ça, ça me déprime fortement parce qu’on n’a pas des masses d’alternatives viables en matière de navigateurs libres.

Download Star

Un remplaçant pour la défunte extension DownThemAll (victime de la suppression de l’ancien système d’extensions) permettant de télécharger en masse les médias affichés ou liés dans une page.

L’interface est peu intuitive, mais en cherchant un peu on s’en sort. Il y a beaucoup d’autres extensions du même type, mais la plupart ont un code fermé et demandent un grand nombre de permissions (ce qui laisse supposer un siphonnage de données perso). Pour celle-là au contraire le code est libre et les permissions demandées sont minimalistes ce qui m’inspire beaucoup plus confiance.

Dark Reader

Une extension qui permet de basculer tous les sites consultés en mode “sombre” pour réduire la fatigue visuelle. Je l’utilise assez peu finalement parce que j’ai la plupart du temps un bon éclairage ambiant (donc je peux m’en passer) et que le rendu étant automatique il est loin d’être toujours très esthétique. Mais ça peut être très utile quand l’éclairage fait défaut.

L’extension permet évidemment d’activer le mode sombre seulement sur certains sites et d’activer ou désactiver le mode en quelques clics.

Simple translate

Dernièrement j’ai eu à traduire beaucoup de documentation technique en anglais. Dans ce cadre j’ai commencé par copier les fragments de textes dans un traducteur automatique (pour finir par retenir celui de Google qui reste le plus efficace), puis copier le résultat et le retravailler un peu pour un résultat satisfaisant (on ne visait pas là de la haute qualité littéraire, juste avoir une version anglaise minimale). Le truc, c’est que ça fait énormément de clics entre deux onglets différents.

Cette extension permet lors de la sélection d’un fragment de texte dans la page d’afficher un encart à côté de la sélection contenant la traduction (via Google). L’avantage, c’est que du coup tout se fait dans la même page et avec bien moins d’opérations puisqu’il suffit de sélectionner le texte puis sélectionner le texte traduit et le copier/coller au bon endroit.

Il est possible d’activer cette traduction en mode automatique ou bien de faire afficher juste un bouton déclenchant la traduction (voir désactiver complètement cet affichage par défaut et passer par le menu contextuel).

Perso une fois le boulot terminé, j’ai désactivé le truc parce que hors processus de traduction, c’est peu utile et envahissant, mais sur le moment ça m’a bien facilité la vie.

Attention cependant, côté Google ils ont un quota de requêtes, du coup comme on était plusieurs collègues à l’utiliser en même temps derrière la même IP, on a fini bloqué en fin de journée (mais c’est revenu le lendemain).

Désactivation du “smart backspace” dans PHP Storm

Suite à une mise à jour de PHP Storm j’étais agacé par un problème d’indentation automatique qui forcément ne fonctionnait pas comme je voulais… En cherchant un peu j’ai fini par trouver.

Dans les préférences : Editor > General > Smart keys, rechercher l’option Smart Backspace et la passer à disabled.

C’est donc raccord avec l’adage qui dit que quand y a smart dans le nom, il faut s’en méfier (en général, c’est de la merde)

Erreur Composer

J’avais le message d’erreur suivant lorsque je tentais un self-update de Composer :

SHA384 is not supported by your openssl extension, could not verify the phar file integrity

En faisant quelques recherches, je n’ai rien trouvé de mieux que de désinstaller Composer puis de le réinstaller…

Puis en regardant la liste des options du self-update je suis tombé sur l’option rollback, j’ai tenté à tout hasard et ça a fonctionné, après ça j’ai pu mettre à jour normalement \o/

php composer.phar self-update -r
php composer.phar self-update

Hachage des mots de passe

Un petit mot sur un point truc que j’ai résolu il y a un moment déjà, mais dont je n’avais pas parlé parce que ça ne me semblait pas justifier un article dédié…

Ça fait un moment que PHP propose une API pour le hachage de mots de passe en vue de les stocker dans une base de données.

Il se trouve que j’ai toujours des forums sous PHPBB 2 (trop customisés pour mettre à jour vers les majeures suivantes), datant d’avant que cette API soit disponible et donc ne s’en servant pas (le standard à l’époque, c’était de stocker un MD5 c’est donc ça que j’avais dans ma base de données).

Pendant un (long) moment, j’ai repoussé le chantier de sécurisation parce que je ne voyais pas de manière propre de gérer ça : n’ayant pas le mot de passe en clair, je ne pouvais pas simplement convertir les mots de passe existants et ne sécuriser que les nouveaux me paraissait bancal.

Puis l’évidence m’a sauté aux yeux : il suffisait de hacher le MD5 plutôt que le mot de passe en clair et de refiler systématiquement le MD5 à l’API lors des vérifications. De cette manière une procédure automatique pouvait me mettre à jour ma base et régler le problème. En 30 minutes, c’était plié.

Rétrospectivement, c’est évident, mais ça a mis du temps à me sauter aux yeux donc si ça peut servir à d’autres…

Sous Windows, j’utilise Tortoise Git. On pourrait épiloguer sur ses qualités et défaut par rapport aux autres clients Git disponibles, mais ce n’est pas le sujet. Je l’utilise principalement parce que je le connais et que je sais que si je fais les choses comme j’en ai l’habitude ça fait ce que j’attends (je trouve ça assez rassurant personnellement).

Il y a peu, j’avais plusieurs commits locaux et je voulais faire un amend sur le second. Plutôt que d’y renoncer je me suis dit que même si je n’avais jamais trouvé ça dans l’interface, il y avait peut-être moyen de réordonner les commits (puisque ça existe en ligne de commande, même si je n’ai jamais réussi à retenir plus de 24 h la marche à suivre les différentes fois où on me l’a expliquée/montrée).

Et j’ai été agréablement surpris de découvrir que oui, c’est possible dans Tortoise Git, même si c’est bien caché (en tout cas moi je ne serais jamais tombé dessus tout seul). J’ai trouvé la réponse la plus claire ici et en voici une traduction en français (mais avec les entrées de menu en anglais parce que j’utilise la version anglophone) :

• ouvrir l’écran de visualisation des logs avec Tortoise Git (“Git show log” sur la racine du dépôt)
• faire un clic droit sur un des commits qui ne soit pas le dernier et sélectionner “rebase {maBranche} onto this”
• dans l’écran de rebasage, sélectionner “FETCH_HEAD” dans le champ “upstream”
• cocher la case “Force rebase”
• la liste des commits s’affiche dans la fenêtre
• cliquer sur le commit à réordonner et utiliser les boutons “Up” et “Down” pour changer sa position
• une fois l’ordre satisfaisant, cliquer sur “Start Rebase”
• c’est fait

Attention : les identifiants des commits réordonnés seront modifiés, veillez donc à bien limiter cette opération à des commits locaux qui n’ont pas encore été propagés sur un dépôt partagé sans quoi vous risquez d’avoir de mauvaises surprises (dans ce cas vous seriez forcé de faire un force push, ce qui est un bon indice qu’il y a un problème) !

Auto Tab Discard

Cette extension permet de libérer automatiquement la mémoire allouée aux onglets que l’on n’a plus consultés depuis un certain temps. La page sera alors rechargée à la prochaine consultation de l’onglet.

L’ensemble est configurable avec la possibilité de définir le délai, des exceptions, etc.

Redirect AMP to HTML

Cette extension a pour but, lorsque vous suivez un lien vers une page AMP (pour Accelerated Mobile Page) de rediriger automatiquement vers la page HTML d’origine.

Avantages :

• on évite de passer par les caches Google (la plupart du temps, c’est Google derrière le cache) ce qui évite de leur fournir des données de consultation et de renforcer encore leur position centrale dominante
• les versions AMP ne sont pas forcément optimisées pour être affichées sur un vrai ordinateur avec un vrai écran (c’est prévu pour les ordiphones)

Textarea Cache

Cette extension va sauvegarder automatiquement les contenus des champs textarea (textes multilignes), ce qui permet de les retrouver lorsqu’on ferme un onglet par erreur (genre par exemple en tapant ctrl + w au lieu de ctrl + x).

Affichage des requêtes XHR

Je ne trouvais pas comment afficher les requêtes XHR dans la console de Firefox (et je me disais que bon ça quand même ils ne doivent pas l’avoir enlevé).

À force de cliquer au hasard, je finis par cliquer sur la petite icône en forme d’entonnoir. Je n’avais pas essayé plus tôt tant ça semblait évidemment lié au champ “filtrer” juste à côté. Mais en fait si c’est comme ça qu’on affiche le panneau pour décider des catégories d’informations qu’on veut afficher…

Retrouver des séparateurs dans les barres d’outils

Un des nombreux trucs qui ont disparu autour de Firefox 57 et de la suppression de XUL c’est le fait de pouvoir mettre des séparateurs entre les boutons d’une barre d’outils.

J’ai cherché un moment, mais pas trouvé de moyen de le refaire via une extension (mais je commence à avoir l’habitude).

Puis je suis tombé sur une solution : passer par userChrome.css en recyclant les espaces flexibles.

C’est très chiant à mettre en œuvre et à déployer sur plusieurs machines, mais au moins ça marche…

Récupérer la barre de statut

Ça non plus ce n’est plus possible via une extension depuis Firefox 57.

Mais ça peut se bricoler dans userChorme.css en recyclant la barre personnelle puis en la plaçant en bas.

Comme pour la barre de statut, c’est laborieux et ça oblige à se passer d’une autre élément.

Heureusement que comme le dit Mitchell Baker dans son appel aux dons, Mozilla est là pour nous aider à personnaliser notre expérience utilisateur ! Imaginez si ce n’était pas le cas…