[ArchLinux] Montage auto des supports amovibles

Jusqu’à présent, mon système Arch était en mesure de monter les supports amovibles, ces derniers s’affichant correctement dans PCManFM. Néanmoins, le démontage par simple clic ne fonctionnait pas: en cause un problème de manque de droit.

À la lecture récente d’un article de blog, je suis tombé sur un court passage vantant les mérites de l’utilitaire udiskie (avec mention de la possibilité de l’intégrer avec pass pour l’ouverture des supports chiffrés LUKS). Je me suis donc lancé dans l’intégration du programme à mon système.

Dans un premier temps, installation via pacman:

sudo pacman -S udiskie

Une fois installé, lancement automatique à l’ouverture de session en ajoutant la ligne suivante dans mon .xinitrc :

udiskie -2 -s &

Les supports amovibles tels que les clés USB, ou les disques durs externes sont désormais démontés sans erreur !

Devoxx France 2018 – Petite sélection

À la mi-avril avait lieu le Devoxx France à Paris, cycle de conférence sur 3 jours, à destination des développeurs. Voici quelques interventions qui ont retenu mon attention.

Laissez tomber Express, passez à son successeur
Présentation de Koa. Plus léger qu’Express, avec juste le minimum et surtout le support des fonctions async par défaut.

Gagner des super pouvoirs avec le terminal
Petit tour d’horizon sur tout ce qu’il est possible de faire directement dans son terminal (avec les « bons » logiciels).

Attention ! Ne mets pas cette clé tu risques de te faire hacker très fort !
Sur le danger de tout ce qui ressemble à une clé USB et ce qu’il est possible de faire avec un micro-controleur très simple.

T’es plutôt merge ou rebase ?
Petit point sur Git.

Les Tests End to End avec des raspberry pi chez leboncoin
Un impressionnant système de test auto sur mobile, construit de zéro.

Quand une documentation devient un problème et que faire alors
Bonnes pratiques et retour d’expérience sur la gestion d’une documentation.

NodeJS 5 bonnes raisons pour lesquelles vous devriez y jeter un oeil
Introduction à NodeJS et l’environnement JS en 2018.

RxJS Les clefs pour comprendre les observables
Quelques explications sur les observables. Quelques exemples intéressants.

Angular et performances
Optimiser Angular. Nouveautés.

RetourAuxSources Les cookies HTTP
Tous savoir sur les cookies !

Ajout du champ Certification Authority Authorization (CAA) à la zone DNS

Je m’étais intéressé il y a de cela plusieurs semaines aux entêtes de sécurité du protocole http et j’en avais également profité pour regarder du côté de la zone DNS. Je m’étais donc occupé d’ajouter un champ CAA, pour Certification Authority Authorisation à la zone DNS de mon domaine.

Quelques mots sur le champ en question. Le but est d’indiquer publiquement quelles autorités de certification sont aptes à générer un certificat pour le domaine concerné (zéro, une ou plusieurs). Si une tentative de génération d’un certificat devait être tenté par une autre autorité, celle-ci devrait échouer car ne figurant pas comme autorité autorisée. A condition bien sûr que l’autorité de certification prenne en compte le champ CAA et le respecte. L’objectif étant de réduire le risque que quelqu’un demande et obtienne un certificat pour votre domaine sans y être autorisé.

Pour la mise en place sur unicoda.com, cela nous donne la configuration suivante :

Trois paramètres possibles: issue, issuewild et iodef. Dans l’ordre, issue restreint la génération des certificats pour le domaine, issuewild restreint la génération de certificat « wildcard » (et ignore tout autre champ comportant issue). Enfin, iodef permet de spécifier un moyen de communication (mailto, http ou https) pour signaler une violation du champ CAA.

Pour davantage d’informations, rien de mieux que d’aller lire directement la RFC : RFC 6844. On peut également consulter les explications de Let’s Encrypt.