↓ Aller au contenu

Weekly #37 : Stalwart 1.0, Tailscale SSH, Home Assistant et BugStage

·1654 mots·8 mins
Cryptolab.re
Auteur
Cryptolab.re
Cryptolab est un blog personnel où je documente mes expérimentations techniques : infra, self-hosting, réseau, crypto et projets parfois inutiles, souvent instructifs.
Sommaire

Stalwart atteint sa première version stable et Home Assistant prépare l’intégration de HACS dans un Marketplace. Je retiens surtout ce que ces annonces promettent pour l’entretien des installations : un schéma de données stabilisé pour le premier, un composant de moins à installer séparément pour le second. Ce Weekly #37, du 24 au 31 octobre 2026, revient aussi sur les correctifs Tailscale SSH, les changements de sondes d’Uptime Kuma et BugStage, une forge pensée pour les mainteneurs qui travaillent seuls.

En bref
#

  • Tailscale : passer les hôtes SSH et les configurations Serve concernées en 1.104.4 ou ultérieure.
  • Stalwart 1.0 : première stable, recherche dans les pièces jointes et migration obligatoire depuis l’ancienne base.
  • Home Assistant : HACS doit devenir le Marketplace en 2026.11, avec reprise automatique de l’installation existante annoncée.
  • Uptime Kuma 2.5.8 : les sondes TCP avec TLS deviennent des sondes TCP simples. Leur portée change.
  • openmediavault 8.6.0 : moins de sondages susceptibles de se bloquer quand un disque répond mal.
  • BugStage : une forge personnelle où les contributions passent par les discussions et les patchs, sans pull requests.

Tailscale SSH : mettre à jour les hôtes qui acceptent les connexions
#

Les correctifs liés au rapport Tailworm sont disponibles dans Tailscale 1.104.4. Le bilan publié par Tailscale le 28 octobre distingue le serveur Tailscale SSH, intégré à tailscaled, d’un serveur OpenSSH simplement joint à travers le VPN. Les problèmes SSH décrits ici concernent le premier.

Le bulletin TS-2026-014 détaille le problème de transfert de sockets Unix : certaines opérations s’exécutaient avec les droits de root au lieu de ceux de l’utilisateur connecté. Un pair autorisé à utiliser SSH et le forwarding pouvait ainsi atteindre des sockets privilégiées, notamment celle de Docker ou l’API locale de tailscaled.

Il faut déjà disposer d’un accès autorisé dans le tailnet et d’une connexion SSH permise par sa politique. Ce scénario permet de dépasser les droits du compte local une fois connecté ; il ne donne pas un accès SSH anonyme depuis Internet. La priorité concerne donc aussi les serveurs partagés dont les utilisateurs SSH ne sont pas censés administrer l’hôte.

Les bulletins voisins couvrent un épuisement mémoire par une session SSH autorisée, ainsi que des problèmes de backends Unix et de capacités HTTP/2 dans Serve. Vérifiez ces usages même si vous n’avez pas activé Tailscale SSH.

Sur chaque hôte Linux qui fournit ces services, cette commande en lecture seule affiche aussi la version du démon local :

tailscale version --daemon

Comparez la version de tailscaled, pas seulement celle du client, à 1.104.4, puis mettez à jour les hôtes concernés vers cette version ou une ultérieure. Relisez également les règles SSH pour retirer les accès devenus inutiles. Référence de la commande

Stalwart 1.0 : une version stable, avec une migration à préparer
#

Stalwart 1.0 est sorti le 26 octobre. Le serveur de messagerie atteint sa première version stable, avec un moteur de recherche revu et l’indexation du texte des PDF et documents bureautiques joints aux messages. Retrouver une référence dans une facture sans savoir quel courriel la contenait, voilà un ajout qui peut servir tous les jours.

L’équipe annonce surtout un schéma de données finalisé, destiné à éviter les migrations intrusives des versions précédentes. Pour une messagerie qu’on souhaite garder plusieurs années, cette perspective compte davantage qu’un classement dans un benchmark.

Le passage à la 1.0 demande toutefois une vraie migration : elle ne peut pas ouvrir une base 0.16. L’outil stalwart-migrate part de 0.16.27 et copie la configuration et les données dans une nouvelle base vide. Prévoyez la place pour cette seconde base ; un stockage externe des pièces jointes peut être réutilisé selon la configuration. La copie initiale et les reprises incrémentales peuvent se faire pendant que l’ancienne instance sert les utilisateurs, puis la copie finale exige son arrêt. Procédure officielle

La source reste en lecture seule pour l’outil. Avant la bascule, utilisez les étapes de vérification et le rapport de migration prévus dans la procédure, en conservant l’ancien déploiement. Les clients OAuth devront se reconnecter et la recherche restera incomplète le temps de reconstruire l’index.

Deux changements de configuration méritent aussi une lecture des notes : Redis devient nécessaire pour un cluster, et les déploiements avec un fournisseur d’identité OIDC externe doivent vérifier les nouvelles exigences OAuth. Le serveur isolé dispose, lui, d’un stockage en mémoire intégré.

Home Assistant : HACS intégré à partir de novembre
#

Franck Nijhof a annoncé le 26 octobre que HACS sera intégré à Home Assistant à partir de 2026.11, sous le nom Marketplace. Il doit apparaître dans les paramètres, sur Home Assistant OS comme sur Container. La reprise des données et le nettoyage de l’ancienne installation HACS sont annoncés comme automatiques.

Pour les nouvelles installations, c’est surtout la fin d’une étape manuelle avant de pouvoir ajouter les intégrations et cartes de la communauté. L’installation d’une intégration peut aussi ouvrir directement son écran de configuration. La documentation de la prochaine version précise que certaines intégrations, notamment celles configurées en YAML, demandent encore un redémarrage ; les mises à jour d’intégrations en demandent toujours un.

Le catalogue reste gratuit. Son intégration à l’interface ne transforme pas les extensions en code officiel : leur contenu n’est ni audité ni pris en charge par le projet Home Assistant. C’est une distinction utile quand on choisit une intégration qui aura accès à la maison et à ses données.

Les autres mises à jour
#

  • Uptime Kuma 2.5.8, publiée le 26 octobre, retire le support TLS des sondes TCP Port et convertit celles qui l’utilisaient en sondes TCP ordinaires. La 2.5.7 du précédent weekly corrigeait encore leurs tentatives supplémentaires : cette fois, la fonction disparaît. Un port ouvert ne valide plus la négociation TLS attendue ; pour un service HTTPS, choisissez une sonde HTTPS. Les notes annoncent aussi un correctif d’exécution de code nécessitant un compte administrateur. Release 2.5.8
  • openmediavault 8.6.0, publiée le 28, lit les informations des systèmes de fichiers dans la base udev plutôt que de relancer blkid à chaque requête. Elle évite aussi le sondage global findmnt --output-all, susceptible de se bloquer sur un disque défaillant. Garder une interface d’administration utilisable quand le stockage va mal, c’est une amélioration bien placée. Notes de version
  • RapidRAW 1.6.7, sortie le 25, se connecte directement à Immich 2.5 ou ultérieur. L’éditeur photo parcourt les albums et la chronologie, télécharge les originaux à l’ouverture ou à l’export, puis conserve les modifications sur le serveur pour les retrouver depuis un autre ordinateur. L’export peut également revenir dans Immich. De quoi éviter une seconde copie complète de la photothèque sur chaque poste de retouche. Présentation de l’intégration
  • Soft Serve a été archivé le 26 octobre. Le dépôt de ce serveur Git en ligne de commande est désormais en lecture seule. C’est un changement à prendre en compte avant de le choisir pour une nouvelle installation. Dépôt du projet

La découverte : BugStage, une forge pour travailler seul
#

BugStage est une forge personnelle créée par l’auteur de PocketBase et construite sur ce même outil. Elle réunit les dépôts Git, les versions publiées, les discussions publiques ou privées et les abonnements aux événements d’un projet, dans un exécutable autonome.

Son choix le plus distinctif est l’absence de pull requests. Une contribution arrive dans une discussion, sous forme de code ou de fichier patch. Pour un mainteneur seul qui préfère commencer par échanger sur un changement, ce fonctionnement mérite un regard : la discussion devient le point d’entrée du travail de revue.

Le périmètre est volontairement étroit. Il n’y a pas de CI/CD fournie, les permissions du rôle mainteneur sont larges et les opérations Git avec go-git restent lentes sur de gros historiques. L’auteur recommande également de disposer de swap pour la consommation mémoire. Cela oriente le projet vers quelques dépôts personnels plutôt que vers une forge d’équipe.

J’aime qu’un projet annonce aussi clairement à qui il s’adresse. On peut ensuite décider si l’on veut cette simplicité, sans découvrir après l’installation que les pull requests étaient justement ce qu’on venait chercher.

À lire : les fuites de données vues par le CERT-FR
#

Le retour d’expérience publié le 20 octobre par le CERT-FR porte sur près de 200 violations de données issues d’applications web suivies en 2025. Dans de nombreux cas, les attaques étaient peu complexes et ne nécessitaient pas l’exploitation d’une vulnérabilité technique. Le rapport propose dix pistes de réduction du risque, accompagnées d’annexes de configuration. Une lecture utile pour examiner une application qui manipule des données sensibles au-delà de sa seule liste de CVE.

La commande de la semaine
#

Les problèmes Tailscale rappellent l’intérêt de savoir quelles sockets Unix existent sur un serveur. Sous Linux avec iproute2, cette commande en lecture seule les liste lorsqu’elles sont en écoute. Les droits administrateur permettent d’identifier les processus des autres comptes :

sudo ss -lxnp

-x sélectionne les sockets Unix, -l celles en écoute et -p les processus associés ; -n évite la résolution des noms. Repérez par exemple les chemins de Docker ou de tailscaled, puis la colonne users, qui donne le nom du processus et son PID. Manuel de ss

Cet inventaire décrit l’environnement local où la commande tourne. La présence d’une socket ne prouve ni qu’un autre utilisateur peut l’ouvrir, ni qu’elle est accessible à travers le tailnet : ses permissions et les règles de transfert restent à examiner.

Bon week-end.

Sources
#

Articles connexes

Weekly #35 : GitLab, Nextcloud, Sonarr 5 et Homelable

·1896 mots·9 mins
GitLab corrige une exécution de code sans authentification, et Collabora publie un avis sur son serveur CODE intégré à Nextcloud. Pour ce dernier, désactiver l’application ne ferme pas le chemin d’attaque : c’est sa version installée qu’il faut vérifier. Deux sujets à traiter avant de passer aux nouveautés de cette sélection du 9 au 16 octobre 2026. Du côté des nouveautés, je retiens les métadonnées en français de Sonarr 5 et les diagrammes de Sync-in. La découverte de la semaine, Homelable, s’attaque à une tâche moins spectaculaire mais bien utile : garder le plan du réseau et sa documentation au même endroit.

Weekly #36 : PHP, Pangolin, KeePassXC et Roborock sans cloud

·1653 mots·8 mins
Pangolin permet désormais d’exporter en YAML les ressources créées dans son interface. J’aime bien ce genre d’ajout : on peut commencer avec des clics, puis récupérer une configuration à relire, à versionner et à reproduire. C’est l’une des bonnes nouvelles de ce Weekly #36, du 17 au 24 octobre 2026, avec KeePassXC 2.8 stable et quelques projets à découvrir. Côté maintenance, les correctifs PHP et GitLab passent en priorité.