Quatre ans sans release

Le dernier release de bcicen/ctop porte le numéro 0.7.7 et date du 22 mars 2022. Le dernier commit dans le dépôt remonte au 1er août 2022. Depuis : rien.

Ce n'est pas une accusation. Celui qui porte seul un projet open source pendant des années peut un jour arrêter. Cela ne change rien au fait que le logiciel continue de fonctionner, sur mes serveurs et dans mes environnements de développement, chaque jour.

J'ai utilisé ctop pendant des années sans jamais examiner le code. Un jour, govulncheck a signalé la première vulnérabilité dans une dépendance, et il était clair que personne ne la corrigerait.

Ce que j'ai trouvé en prenant le relais

Le code était bien écrit, mais datait de 2022.io/ioutil au lieu de os, un package de journalisation non maintenu depuis des années, une bibliothèque UUID provenant d'un compte supprimé.

Trois vulnérabilités ont été identifiées lors de la première phase.container.Exec()transmettait les entrées utilisateur via sh -c, permettant une injection de shell. Le fichier de configuration a été créé avec des permissions de lecture pour tous. Le serveur de débogage écoutait sur 0.0.0.0, et était donc accessible sur tout le réseau dès qu'un utilisateur CTOP_DEBUG=1l'activait.

Un quatrième problème a été découvert plus tard dans le connecteur runC : un canal jamais initialisé. Les appels Send et Receive bloquent indéfiniment en Go. Le code fonctionnait uniquement parce que ce chemin n'était pratiquement jamais atteint.

Pour ce que je m'engage à faire

Je ne promets pas de nouvelles fonctionnalités chaque mois. Ce que je garantis, c'est une approche plus ciblée et robuste.

Les dépendances restent à jour. Dependabot examine hebdomadairement les modules Go, GitHub Actions et l'image de base Docker, et govulnchecks'exécute dans la chaîne de construction et arrête le processus si une vulnérabilité connue est détectée.

Les problèmes de sécurité sont corrigés, pas documentés et laissés en l'état. Lorsque runC a signalé trois contournements de conteneur en automne 2025, une mise à jour a été publiée, suivie d'une seconde en novembre.

Des builds sont disponibles pour cinq plateformes. Chaque version inclut des binaires pour Linux, macOS et Windows avec leurs sommes SHA256, une image multi-architecture sur GHCR et une formule Homebrew mise à jour. Tout est déclenché par un tag Git ; le reste est géré par GitHub Actions.

Ce que le fork ne sera pas

Aucune réécriture. Aucune course aux fonctionnalités contre lazydocker ou k9s. ctop reste un outil qui fait une seule chose.

Un changement plus important est néanmoins prévu. Les deux bibliothèques sur lesquelles l'interface terminal se base, gizak/termui und nsf/termbox-go, ne sont plus maintenues. Le plan pour la transition vers le stack Charm se trouve sous forme de document en six phases dans le dépôt. Je n'ai pas encore commencé.

Ce que l'outil peut faire aujourd'hui et comment vous l'installez, est indiqué dans la vue d'ensemble du projet. Si vous utilisez ctop et que quelque chose manque ou est bloqué : les problèmes sont ouverts, les demandes de tirage aussi.