Steve French, 24 ans de CIFS/SMB3, cède la maintenance du sous-système à deux successeurs

22 août 2026. 2002. 24 ans. Le 22 août 2026, le noyau Linux a intégré un patch qui marque la fin d’une époque : Steve French, mainteneur et principal auteur du code CIFS/SMB2/SMB3, se retire pour raisons de santé. Le même jour, la communauté a appris via Jeremy Allison — développeur historique de Samba, aujourd’hui chez CIQ — qu’il était décédé. C’est le code qui permet à chaque machine Linux de parler aux serveurs de fichiers Windows, aux NAS et au stockage Azure qui perd son architecte.

Ce n’est pas un simple changement de mainteneur. C’est une leçon sur le bus factor — le nombre de personnes dont la disparition suffirait à mettre un composant critique en péril — appliquée à l’un des sous-systèmes les plus discrets et les plus universels du noyau.

Un sous-système invisible mais universel

CIFS/SMB3 est le client du protocole Server Message Block dans le noyau Linux. Concrètement, c’est lui qui monte les partages Windows (mount -t cifs), accède aux volumes SMB des NAS grand public comme professionnels, et connecte les serveurs Linux aux comptes de stockage Azure Files. KSMBD, le serveur SMB intégré au noyau que French maintenait également, fait le chemin inverse : il transforme un Linux en cible SMB native, sans passer par Samba en espace utilisateur.

La portée est massive. Toute entreprise qui fait cohabiter des parcs Windows et Linux — c’est-à-dire presque toutes — dépend de ce code à chaque montage, à chaque accès fichier. Or cette dépendance reposait, depuis l’amont, sur un seul homme.

Steve French a commencé à contribuer au noyau en 2002, quand l’amont du client CIFS VFS a démarré. Ingénieur IBM de longue date, il a rejoint Microsoft en 2018 pour travailler sur Azure Storage — tout en restant mainteneur amont du code CIFS et de KSMBD. Vingt-quatre ans de contribution continue, dans l’ombre des annonces plus visibles du noyau.

Le patch qui acte la succession

Le changement est acté par un commit désormais fusionné dans la branche de Linus Torvalds (614b9fb585f143d65162f17f1a4b4ec4cbdf5794). Il désigne Paulo Alcantara et Namjae Jeon comme co-mainteneurs de CIFS/SMB3.

Deux co-mainteneurs plutôt qu’un seul n’est pas un détail : c’est précisément la réponse structurelle au bus factor qui vient de se révéler. Un sous-système critique porté par une personne est un point de défaillance organisationnel — pas technique. La double mainteneur réduit ce risque, mais elle ne remplace pas la mémoire institutionnelle : vingt-quatre ans d’arbitrages, de correctifs de compatibilité avec des implémentations SMB buguées, de cas limites protocolaires.

Le timing, lui, n’est pas neutre. La démission est tombée alors que s’ouvrait la fenêtre de fusion de Linux 7.3. Le sous-système va donc changer de mainteneur en plein cycle de développement, avec un flux de correctifs déjà engagé — un test immédiat pour la nouvelle équipe.

Pourquoi le bus factor n’est pas une métaphore

Le cas CIFS/SMB3 illustre un problème structurel de l’open source que les entreprises consomment sans le voir. Un composant peut être mature, largement déployé et peu médiatisé à la fois — c’est souvent précisément là que se concentre la dépendance à un individu.

# Qui maintient réellement ce que vous montez en production ?
# Le fichier MAINTAINERS du noyau liste les responsables par sous-système :
grep -A 6 'CIFS' /usr/src/linux/MAINTAINERS 2>/dev/null || echo "MAINTAINERS non disponible"

La leçon dépasse le noyau. Pour un SRE ou un RSSI, la question à se poser n’est pas « ce composant a-t-il des correctifs récents », mais « combien de personnes peuvent le maintenir, et que se passe-t-il si elles disparaissent ». C’est une question de continuité de service, pas de sécurité au sens étroit — même si une faille non corrigée faute de mainteneur devient vite une faille tout court.

La communauté a répondu de façon saine : la transition est ordonnée, le sous-système passe à deux mains, et l’expression de gratitude a été massive sur les listes, les réseaux et les messages de commit eux-mêmes. C’est le meilleur scénario possible après une perte humaine.

Une surface d’attaque, pas seulement un chemin de données

Le client SMB n’est pas qu’un tuyau vers les fichiers : c’est une surface d’attaque. Le noyau parse des structures de protocole arrivant du réseau, et un serveur malveillant peut tenter d’exploiter un défaut de parsing pour obtenir une exécution de code. Le blog ETTAYEB documente cette réalité chaque mois : les correctifs du noyau incluent régulièrement des failles CIFS, KSMBD ou du parseur SMB, dont certaines remontent à des années. Un sous-système dont le mainteneur part sans succession, c’est un sous-système où la prochaine faille à CVSS élevé risque de mettre plus longtemps à être corrigée.

La distinction entre les deux étages compte ici. Samba, en espace utilisateur, s’appuie sur une communauté large et une fondation dédiée. Le client CIFS et KSMBD, eux, vivent dans le flux du noyau : un comité plus restreint, une responsabilité plus lourde, et une exposition directe au niveau du kernel. Quand un tel composant change de mainteneur, la vraie question n’est pas « qui va fusionner les correctifs », mais « qui va trier en urgence la prochaine faille critique ».

Mesurer son bus factor tient en trois questions : qui a écrit ce composant, combien de personnes peuvent le modifier sans rien casser, et que se passerait-il s’ils partaient demain. La réponse est presque toujours inconfortable — c’est précisément pour cela qu’il faut la poser avant la crise, pas après.

Ce que ça change concrètement

Pour l’utilisateur final, rien ne casse immédiatement. Le code reste le même, la compatibilité SMB2/SMB3 ne change pas, et les correctifs continueront d’arriver. Mais trois choses bougent à moyen terme :

• La vitesse de traitement. Un nouveau mainteneur met des mois à acquérir le réflexe sur les cas limites. Attendez-vous à un rythme de revue plus prudent sur CIFS/SMB3 pendant quelques cycles.
• Le risque de régression. Les implémentations SMB historiques (anciens NAS, vieux Windows Server) dépendent de contournements accumulés sur deux décennies. C’est là que la mémoire institutionnelle se perd en premier.
• La vigilance accrue. Si vous montez des volumes SMB en production, surveillez de plus près les changements de version du noyau sur vos hôtes de fichiers dans les prochains mois — le sous-système vient de changer de pilote.

La contrepartie positive : la succession à deux co-mainteneurs est une bonne nouvelle structurelle, et KSMBD comme le client CIFS restent activement développés. Le sous-système n’est pas orphelin.

Verdict

Si vous exploitez des montages SMB/CIFS en production, ne changez rien d’urgence : la compatibilité reste intacte et la maintenance est assurée par deux co-mainteneurs. Mais profitez de cette transition pour cartographier vos dépendances à un seul mainteneur — au noyau comme dans vos outils maison. C’est le moment de documenter ce qui repose sur une personne.

Si vous maintenez vous-même du code open source, la leçon est plus directe : un composant critique ne devrait jamais avoir un bus factor de 1. La succession de CIFS/SMB3 est un modèle — deux co-mainteneurs désignés avant l’urgence — que peu de projets ont eu la discipline d’appliquer.

Le fond de l’histoire dépasse le protocole. Steve French a passé 24 ans à maintenir le code qui fait dialoguer deux mondes qui ne s’aiment pas. Sa disparition rappelle que la résilience d’une infrastructure ne tient pas seulement à la redondance des machines, mais à la redondance des humains qui la portent.

Références

• Longtime Linux CIFS/SMB3 Maintainer Passes Away — Phoronix, 22 août 2026
• Commit de changement de mainteneur CIFS/SMB3 — kernel.org, 22 août 2026
• This Week in Open Source: August 23, 2026 — Tech on Linux, 23 août 2026