Weekly #27 : rsync 3.5, Postfix, Firefox, SQLite et Planka

Deux mises à jour méritent de remonter dans la file de maintenance : rsync 3.5.0 corrige 33 problèmes de sécurité, et Postfix publie des correctifs pour plusieurs branches encore déployées. Les scénarios ne touchent pas tous les systèmes de la même manière, mais les services exposés et les transferts avec des pairs non maîtrisés doivent être vérifiés en priorité.

Le reste de la semaine illustre trois risques plus discrets : une rotation de clé qui casse certains dépôts RPM, une condition de concurrence SQLite très rare mais capable de corrompre une base, et une mise à jour Planka qui désactive les comptes SSO si elle est appliquée sans préparation.

En bref

#

• rsync : passer à 3.5.0 ou au paquet corrigé par la distribution. Les versions jusqu’à 3.4.4 sont concernées par tout ou partie des 33 avis.
• Postfix : installer 3.11.6, 3.10.13, 3.9.14 ou 3.8.20 selon la branche. Les versions 3.5 à 3.7 reçoivent aussi un correctif ponctuel, sans redevenir supportées.
• Firefox et Thunderbird : aucune action pour la plupart des utilisateurs. Les dépôts RPM Mozilla sur certaines distributions demandent une rotation manuelle de clé.
• SQLite : le bug WAL-Reset est corrigé depuis 3.51.3, ainsi que dans les rétroportages 3.44.6 et 3.50.7. Le risque est faible avec la configuration WAL standard.
• Planka : ne pas passer à la 2.2.0 sans compte administrateur local si l’instance utilise OIDC/SSO.

rsync 3.5.0 corrige 33 problèmes de sécurité

#

Le projet rsync présente la 3.5.0 comme une version de sécurité majeure. Elle corrige 33 problèmes découverts lors d’un audit ciblé sur la gestion des chemins, d’une campagne de fuzzing du protocole daemon et de signalements externes.

La liste est trop large pour être résumée par un seul scénario. Elle comprend notamment :

• des sorties de répertoire avec rrsync, --relative, certains chemins temporaires et plusieurs configurations de daemon sans chroot ;
• des lectures, écritures ou suppressions hors de l’arborescence attendue via des courses sur les liens symboliques ;
• des injections de commandes ou d’arguments à partir de valeurs contrôlées par le pair ;
• plusieurs écritures hors limites en mémoire ;
• des dénis de service sur le daemon ;
• un contournement de hosts deny en cas d’échec de résolution DNS ;
• une usurpation d’adresse source quand le mode PROXY protocol accepte directement des clients non fiables ;
• une connexion TLS non authentifiée dans rsync-ssl.

Un des avis est classé critique par le projet, mais cela ne signifie pas que toute machine ayant rsync installé est immédiatement exploitable. Plusieurs chemins exigent une configuration particulière : daemon avec use chroot = no, module accessible en écriture, compte restreint par rrsync, proxy protocol = true, convertisseur de noms ou hook externe.

Le client n’est pas hors sujet pour autant. Certaines failles sont atteignables lorsqu’il reçoit des données d’un serveur malveillant ou lorsque des chemins fournis à rsync peuvent être remplacés par des liens symboliques. Une sauvegarde tirée depuis un serveur moins fiable mérite donc la même attention qu’un daemon écoutant sur le port 873.

Contrôles rapides :

rsync --version | head -1
ss -ltnp | rg ':873\b'
systemctl status rsync --no-pager

Pour les daemons, il faut aussi relire les paramètres réellement appliqués :

rg -n '^(use chroot|read only|auth users|hosts allow|hosts deny|proxy protocol)' \
  /etc/rsyncd.conf /etc/rsyncd.conf.d/*.conf 2>/dev/null

La recommandation amont est simple : passer à 3.5.0. Sur Debian, Ubuntu, RHEL ou une autre distribution stable, le numéro du paquet peut rester inférieur si les correctifs sont rétroportés. Il faut donc consulter l’avis du fournisseur avant de compiler une version amont sur un serveur de production.

La surface à traiter en premier est claire : daemon exposé, modules en écriture, transferts avec des pairs non maîtrisés et comptes rrsync utilisés comme confinement.

Avis de sécurité rsync 3.5.0
Notes de publication rsync 3.5.0

Postfix : dénis de service et contournements de politiques

#

Postfix publie les versions 3.11.6, 3.10.13, 3.9.14 et 3.8.20. Des versions correctives existent également pour les branches 3.7, 3.6 et 3.5, désormais hors support.

L’annonce amont parle de problèmes d’impact moyen. Deux catégories sont directement pertinentes pour un serveur SMTP exposé.

La première concerne l’état du protocole après le rejet d’un message par smtpd_end_of_data_restrictions. Dans certaines conditions, un client distant pouvait envoyer un second message sans nouvelle commande MAIL FROM. Des contrôles basés sur check_recipient_access pouvaient alors être sautés. Un état accept conservé côté Milter pouvait également éviter l’application de la politique au second message.

La seconde concerne la disponibilité :

• de nombreuses petites requêtes BDAT pouvaient épuiser la mémoire utilisée pour l’historique des commandes ;
• une erreur BDAT, suivie d’une séquence spécialement construite, pouvait faire tomber un processus SMTP par lecture d’un pointeur nul ;
• un utilisateur local pouvait empoisonner négativement le cache de vérification d’adresse avec postdrop sur les systèmes qui activent cette fonction.

Le modèle multiprocessus de Postfix limite une partie des crashs à un processus enfant. Le déni de service par consommation mémoire reste toutefois pertinent pour un service joignable depuis Internet. Le contournement de politique dépend de la configuration réellement utilisée, en particulier des restrictions de fin de données et des Milters.

Vérifier la branche installée et les mécanismes concernés :

postconf mail_version
postconf -n | rg 'smtpd_end_of_data_restrictions|smtpd_milters|non_smtpd_milters|address_verify'
ss -ltnp | rg ':(25|465|587)\b'

Les paquets des distributions peuvent intégrer les correctifs sans reprendre exactement le numéro amont. Là encore, la version du paquet et l’avis du fournisseur font foi.

Les builds 3.7.22, 3.6.20 et 3.5.27 corrigent ces nouveaux défauts, mais l’amont précise qu’ils n’incluent pas automatiquement tous les correctifs publiés en juin sur les grandes entrées SMTP, le parsing TLSA et le SMTP smuggling. Une branche hors support ne doit pas être considérée comme remise à niveau par cette seule publication.

Annonce Postfix 3.11.6 et branches corrigées

Mozilla remplace une sous-clé de signature Firefox et Thunderbird

#

Mozilla a révoqué une sous-clé GPG utilisée pour signer certains artefacts Firefox et Thunderbird après la découverte d’une copie privée non chiffrée dans un dépôt GitHub privé.

Les artefacts concernés par cette sous-clé sont :

• les archives Linux ;
• les paquets RPM Firefox publiés par Mozilla ;
• les fichiers de sommes de contrôle.

Mozilla indique n’avoir trouvé aucun accès non autorisé dans les journaux disponibles. Le dépôt était accessible à un petit groupe de personnes qui disposaient déjà légitimement de la clé par ailleurs. Ce n’est donc pas une preuve de compromission de Firefox ni de publication d’un binaire malveillant.

La plupart des utilisateurs n’ont rien à faire. Les installations gérées par le paquet natif de leur distribution, Flatpak ou un canal qui ne s’appuie pas sur ce dépôt RPM ne sont pas concernées par la procédure manuelle décrite par Mozilla.

Deux cas demandent une action :

• les équipes qui vérifient manuellement les signatures GPG doivent importer la nouvelle sous-clé et la révocation de l’ancienne ;
• Fedora 42 et versions antérieures, RHEL, Rocky Linux, AlmaLinux et openSUSE ne remplacent pas toujours correctement la clé du dépôt RPM Mozilla.

La nouvelle sous-clé porte l’empreinte suivante et expire le 5 août 2028 :

827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3

Sur Fedora 43 et versions ultérieures, dnf propose l’import lors de la prochaine mise à jour. Il faut comparer l’empreinte affichée avant de l’accepter.

Sur les distributions plus anciennes citées par Mozilla, la procédure officielle retire d’abord l’ancienne clé, importe la nouvelle, puis vide le cache :

sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353
sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg
sudo dnf clean all

Pour openSUSE, la dernière commande devient sudo zypper refresh. Le retrait de clé ne doit pas être automatisé sur un parc sans vérifier que les machines utilisent bien le dépôt Mozilla visé.

Avis Mozilla et procédure de rotation GPG

SQLite WAL-Reset : une corruption possible, mais très rare

#

Tailscale a publié le retour d’expérience complet sur une série de corruptions SQLite ayant perturbé son control plane. L’enquête menée avec les développeurs SQLite a isolé une course entre un checkpoint et une transaction d’écriture en mode WAL.

Dans une fenêtre temporelle très étroite, une connexion peut réinitialiser le WAL pendant qu’une autre démarre un checkpoint. Le second checkpoint ne voit pas correctement la réinitialisation et marque des pages comme déjà copiées dans le fichier principal. Lors d’un checkpoint ultérieur, certaines pages sont sautées. Des données validées peuvent être perdues et la base devient incohérente.

Le bug est probablement présent de SQLite 3.7.0 à 3.51.2. Il est corrigé dans :

• SQLite 3.51.3 et versions ultérieures ;
• les rétroportages 3.44.6 et 3.50.7.

Pour être exposée, une base doit utiliser le mode WAL, être ouverte par au moins deux connexions dans des threads ou processus distincts, et subir au même instant un checkpoint et une écriture. L’équipe SQLite estime que l’occurrence observée dans la nature reste comparable ou inférieure à celle d’une défaillance SSD ou d’une erreur matérielle rare. Ce n’est pas une urgence générale pour chaque application embarquant SQLite.

Tailscale cumulait cependant les facteurs favorables : checkpoints pilotés manuellement, rythme agressif et grand nombre de bases. Dix-neuf corruptions ont été observées en six mois. Les premières récupérations ont parfois perdu quelques appareils récemment ajoutés ou des changements de configuration, sans exposer les clés privées ni le trafic des utilisateurs.

Vérifications en lecture seule sur une base accessible avec le client SQLite :

sqlite3 --version
sqlite3 -readonly /chemin/base.db 'PRAGMA journal_mode;'
sqlite3 -readonly /chemin/base.db 'PRAGMA quick_check;'

Sur une grosse base active, quick_check peut consommer des I/O et doit de préférence être exécuté sur un snapshot cohérent. La version affichée par le binaire sqlite3 ne garantit pas celle liée statiquement dans une application ou un conteneur. Pour les logiciels embarqués, il faut vérifier la bibliothèque réellement livrée par le projet.

La première version ayant intégré le correctif, SQLite 3.52.0, a été retirée après la découverte d’un second problème autour des index d’expressions devenus obsolètes à la suite d’un changement d’arrondi. La 3.51.3 ne contient que le correctif WAL-Reset, et la 3.53.0 ajoute un mécanisme d’auto-réparation pour certains index d’expressions. Il ne faut donc pas recommander la 3.52.0 comme cible de mise à jour.

SQLite - documentation du bug WAL-Reset
Tailscale - retour d’expérience sur les corruptions SQLite
SQLite - index d’expressions obsolètes

Planka 2.2 retire OIDC/SSO de l’édition communautaire

#

Planka 2.2.0 déplace OIDC/SSO vers l’édition Pro. La décision commerciale peut se discuter, mais le risque immédiat est purement opérationnel : une mise à jour non préparée peut verrouiller l’accès à l’instance.

Après passage à la 2.2.0, les comptes qui utilisaient uniquement le SSO sont désactivés, puisqu’ils ne disposent pas de mot de passe local. Un administrateur peut leur définir un mot de passe et les réactiver. Si l’unique compte administrateur dépend du SSO, personne ne pourra toutefois se connecter pour effectuer cette opération.

Avant la mise à jour :

1. inventorier les comptes OIDC et vérifier qu’un administrateur local fonctionne réellement ;
2. sauvegarder la base et la configuration ;
3. décider si le SSO doit être conservé via Planka Pro, une version communautaire antérieure maintenue temporairement ou une migration vers un autre outil ;
4. tester la restauration et le retour arrière ;
5. prévenir les utilisateurs de la méthode d’authentification retenue.

Rester sur une ancienne image conserve le SSO, car Planka ne le désactive pas à distance. Ce n’est néanmoins pas une stratégie durable : il faut alors assumer les correctifs de sécurité et de dépendances qui ne seront plus reçus sur cette version.

La 2.2.0 ajoute en parallèle le TOTP pour les comptes locaux, la déconnexion automatique après inactivité et la gestion des appareils de confiance. Les installations manuelles exigent désormais Node.js 24, tandis que les utilisateurs de l’image Docker n’ont pas à gérer ce runtime directement. Les builds ARMv7 ont également été retirés.

Notes de publication Planka 2.2.0
Discussion Planka sur le déplacement du SSO

Signaux de veille cette semaine

#

HestiaCP 1.10.0 concentre beaucoup de changements sensibles. La release ajoute notamment le support d’Ubuntu 26.04, prépare Debian 13, prend en charge PHP 8.5 et Roundcube 1.7, permet de limiter phpMyAdmin au SSO Hestia et corrige plusieurs problèmes de validation, d’injection et de contrôle d’accès. Les versions de service 1.10.1 et 1.10.2 ont suivi dans les heures suivantes. Pour un panel qui pilote le web, le mail, le DNS et les sauvegardes, mieux vaut tester directement la 1.10.2 sur un clone que déployer la 1.10.0 initiale.

Nextcloud publie les maintenances 32.0.14, 33.0.8 et 34.0.3. Elles correspondent respectivement aux branches Hub 25 Autumn, 26 Winter et 26 Spring. Nextcloud mentionne des correctifs de sécurité, de stabilité et de fonctionnement sans détailler de vulnérabilité publique dans l’annonce. Sauvegarde, vérification des applications tierces et test de restauration restent les étapes utiles avant la mise à jour.

L’équipe Nixpkgs core se dissout après dix mois. Ses deux membres actifs expliquent que la charge, l’attrition et les difficultés de délégation avec le Steering Committee rendaient le rôle intenable. Les sujets relevant de l’équipe n’ont plus de responsable direct et reviennent au Steering Committee en dernier recours. Nixpkgs ne s’arrête pas, mais l’incident révèle un risque de gouvernance et de capacité de décision sur un dépôt central pour l’écosystème Nix.

Le kit ESPHome abaisse la marche d’entrée dans l’électronique locale. Conçu par Apollo Automation pour l’Open Home Foundation, il repose sur un ESP32-C6 et fournit des modules de mouvement, température/humidité, notification et bouton, reliés par nappes sans soudure. Le Device Builder peut configurer les premiers projets sans YAML, tout en laissant le code accessible. Les appareils fonctionnent localement et s’intègrent à Home Assistant, sans dépendance cloud annoncée.

HestiaCP 1.10.0 et 1.10.2
Nextcloud - mises à jour de maintenance d’août
NixOS - dissolution de l’équipe Nixpkgs core
ESPHome Starter Kit

Les pépites de la semaine

#

Nextcloud Native propose un client indépendant en alpha pour Android, Linux et Windows. Il utilise les API du serveur pour présenter Files, Photos, Talk, Calendar et d’autres applications dans une interface native, sans simple wrapper web. Les paquets macOS restent incomplets et iOS est annoncé mais indisponible. Le projet recommande lui-même de conserver une autre copie des données importantes pendant l’alpha.

Hammer est un environnement d’écriture de romans avec clients desktop et mobile, scènes, chronologies, notes et encyclopédie de personnages. Le serveur de synchronisation peut être déployé avec Docker. Pour un usage uniquement desktop, le projet documente aussi une synchronisation externe, par exemple avec Syncthing. C’est un cas d’usage plus spécialisé que les habituels outils de notes, mais le modèle auto-hébergé est cohérent pour des manuscrits privés.

Arcane fournit une interface moderne pour gérer Docker et Compose, avec un backend Go et une interface SvelteKit. Le projet publie son SBOM et une politique de sécurité. Comme toute interface ayant la capacité de créer et modifier des conteneurs, elle détient pratiquement les clés de l’hôte Docker : authentification forte, accès réseau restreint et sauvegarde des fichiers Compose sont plus importants que l’esthétique du tableau de bord.

Nextcloud Native
Hammer
Arcane

Commande du jour

#

sqlite3 -readonly /chemin/base.db '.dbinfo'

La commande .dbinfo affiche des informations structurelles sur une base SQLite sans la modifier : taille de page, nombre de pages, version du schéma et autres métadonnées utiles au diagnostic.

Elle ne donne pas la version de la bibliothèque utilisée par l’application. Pour cela :

sqlite3 --version

Sur une application qui embarque SQLite statiquement, la vérification doit se faire dans le binaire, le conteneur ou la documentation de la version réellement déployée.

Conclusion

#

L’ordre de travail raisonnable est de vérifier rsync et Postfix, surtout lorsqu’ils sont exposés ou échangent avec des tiers. La rotation Mozilla demande une intervention ciblée sur certains dépôts RPM, pas une réinstallation générale de Firefox. SQLite mérite un inventaire des versions embarquées et des sauvegardes cohérentes, sans déclencher une migration urgente de toutes les applications. Enfin, une instance Planka utilisant le SSO doit être préparée avant toute mise à jour vers la 2.2.0.

Sources

#

• rsync - avis de sécurité 3.5.0
• rsync 3.5.0 - notes de publication
• Postfix 3.11.6, 3.10.13, 3.9.14, 3.8.20 et correctifs legacy
• Mozilla - nouvelle sous-clé GPG Firefox et Thunderbird
• SQLite - WAL-Reset bug
• SQLite - Stale Expression Indexes
• Tailscale - How we tracked down a 16-year-old SQLite bug
• Planka 2.2.0
• Planka - OIDC/SSO moves to Planka Pro
• HestiaCP 1.10.0
• HestiaCP 1.10.2
• Nextcloud - mises à jour de maintenance d’août
• NixOS - The Nixpkgs core team has disbanded
• ESPHome - Starter Kit
• Nextcloud Native
• Hammer
• Arcane