Vier Jahre ohne Release

Der letzte Release von bcicen/ctop trägt die Nummer 0.7.7 und stammt vom 22. März 2022. Der letzte Commit im Repository ist vom 1. August 2022. Seitdem: nichts.

Das ist kein Vorwurf. Wer ein Open-Source-Projekt jahrelang alleine trägt, darf irgendwann aufhören. Nur ändert das nichts daran, dass die Software weiterläuft, auf meinen Servern und in meinen Entwicklungsumgebungen, jeden Tag.

Ich habe ctop über Jahre benutzt, ohne je in den Code zu schauen. Irgendwann meldete govulncheck die erste Schwachstelle in einer Abhängigkeit, und es war klar, dass sie niemand beheben würde.

Was ich beim Übernehmen vorgefunden habe

Der Code war gut geschrieben, aber der Stand von 2022. io/ioutil statt os, ein Logging-Paket, das seit Jahren nicht mehr gepflegt wird, eine UUID-Bibliothek von einem gelöschten Account.

Ernster waren drei Funde aus der ersten Runde. container.Exec() reichte Benutzereingaben über sh -c weiter, was eine Shell-Injection erlaubte. Die Konfigurationsdatei wurde mit Weltleserechten angelegt. Und der Debug-Server band auf 0.0.0.0, war also im gesamten Netzwerk erreichbar, sobald jemand CTOP_DEBUG=1 setzte.

Im runC-Connector kam später ein vierter dazu: ein Channel, der nie initialisiert wurde. Sends und Receives darauf blockieren in Go still und ewig. Der Code lief nur deshalb, weil dieser Pfad in der Praxis selten getroffen wurde.

Wofür ich geradestehe

Ich verspreche keine neuen Funktionen im Monatstakt. Was ich zusage, ist enger und dafür belastbar.

Abhängigkeiten bleiben aktuell. Dependabot prüft wöchentlich Go-Module, GitHub Actions und das Docker-Base-Image, und govulncheck läuft in der Build-Pipeline und bricht ab, wenn eine bekannte Schwachstelle durchrutscht.

Sicherheitsprobleme werden gepatcht, nicht dokumentiert und liegen gelassen. Als runc im Herbst 2025 drei Container-Escapes meldete, gab es dafür einen Release, und beim Nachschlag im November noch einen zweiten.

Builds gibt es für fünf Plattformen. Jeder Release liefert Binaries für Linux, macOS und Windows samt SHA256-Summen, ein Multi-Arch-Image auf GHCR und eine aktualisierte Homebrew-Formula. Ausgelöst wird das von einem Git-Tag, alles Weitere macht GitHub Actions.

Was der Fork nicht wird

Kein Rewrite. Kein Feature-Wettlauf mit lazydocker oder k9s. ctop bleibt ein Werkzeug, das eine Sache macht.

Eine größere Umstellung steht trotzdem an. Die beiden Bibliotheken, auf denen die Terminaloberfläche aufbaut, gizak/termui und nsf/termbox-go, sind selbst nicht mehr gepflegt. Der Plan für den Umstieg auf den Charm-Stack liegt als Sechs-Phasen-Dokument im Repository. Angefangen habe ich damit noch nicht.

Was das Tool heute kann und wie du es installierst, steht auf der Projektübersicht. Wenn du ctop einsetzt und etwas fehlt oder klemmt: Issues sind offen, Pull Requests auch.