Ja genau da liegt für mich ehrlich gesagt das Problem. Es geht dabei gar nicht darum, dass deine KI irgendwann Skynet startet, die Menschheit auslöscht oder absichtlich irgendwas Böses in deinen Code einbaut. xD
Dafür reicht ein fehlerhafter oder unsicherer Code vollkommen aus und davon habe ich in deinem Projekt mittlerweile leider genug gefunden.
Wenn du deine KI sowieso für die Entwicklung nutzt, dann kannst und musst du sie meiner Meinung nach auch dafür nutzen, ihren eigenen Code nochmal auf Sicherheitsprobleme, unsichere Standardeinstellungen und so Sachen wie deine READMEs zu prüfen.
Natürlich ersetzt das keine richtige Sicherheitsprüfung. Aber es ist schon mal wesentlich besser, als den Code einfach zu übernehmen, kurz zu gucken ob die Funktion tut was sie soll und ihn danach zu veröffentlichen. Denn genau da liegt für mich der entscheidende Unterschied: Nur weil eine Funktion funktioniert, heißt das noch lange nicht, dass sie sicher ist. Das habe ich dir jetzt ja leider schon mehrfach demonstriert.
Ich habe mir deinen aktuellen Stand inzwischen etwas genauer angesehen und da sind immer noch ein paar Sachen drin, die ich bei einem Tool mit SSH- und Root Rechten schon ziemlich riskant finde.
Die größten Baustellen sind:
- Bei verschiedenen Skript-Funktionen werden Dateinamen weiterhin direkt in Shell-Befehle eingebaut. Teilweise laufen diese Befehle anschließend sogar als root.
- Bei den geplanten Backups kann dein tar mit Fehlern durchlaufen und das Archiv wird trotzdem weiter als vollständiges Backup behandelt. Danach werden ältere Backups automatisch gelöscht ohne Verifizierung. Damit hätte man dann im ungünstigsten Fall ein kaputtes oder unvollständiges Backup. Das finde ich bei einer Backup-Funktion schon ziemlich sportlich.
- Die geplanten Backup-Jobs werden aus einer JSON-Datei wieder zu Root-Cronjobs. Die Werte werden im aktuellen Stand nicht überall geprüft, bevor sie in /etc/cron.d landen.
- Bei Uploads hast du noch ein chown -R auf Zielverzeichnisse. Existiert der Ordner oder eine UGOS Freigabe schon, kannst du damit die Besitzer eines kompletten vorhandenen Verzeichnisbaums verändern.
- Bei Docker gibt es Funktionen, die Mountpfade nehmen und darauf rekursiv chmod 777 ausführen. Bei deinem Tool würde ich sowas wirklich nur machen, wenn es wirklich erforderlich ist.
- Dein Schutz- bzw. Vollzugriffsmodus ist standardmäßig freigeschaltet. Im Code steht sogar danger_functions_unlocked = True. Bei einem Tool, das Root Cron schreiben, Snapshots löschen, Systemkonfiguration verändern und mit dd Datenträger beschreiben oder löschen kann, würde ich das ehrlich gesagt genau anders herum machen: erstmal alles zu und der User muss die gefährlichen Funktionen bewusst selbst freischalten.
- Auch deine automatische Update-Funktion würde ich nochmal überarbeiten. Die SHA-256-Prüfung ist auf jeden Fall besser als vorher, aber Installer und Prüfsumme kommen beide aus demselben GitHub-Release. Falls dein GitHub-Account bzw. dein Veröffentlichungsprozess irgendwann kompromittiert wird, kann jemand einen manipulierten Installer samt passender Prüfsumme veröffentlichen. Deine App sagt dann sinngemäß „Hash stimmt“ und startet anschließend einen nicht signierten Installer, der Administratorrechte verlangt und somit die Nutzer gefährdet.
Und das sind jetzt wirklich nur die größeren Sachen.
Was ich dir eigentlich damit sagen will: Du musst als privater Entwickler selbstverständlich kein komplettes Sicherheitsteam beschäftigen, aber du kannst dir mit ziemlich wenig Aufwand schon sehr viel Arbeit abnehmen.
Änderungen nur noch über Pull Requests, automatische Tests vor dem Zusammenführen der Änderungen, CodeQL oder ähnliche Prüfungen, regelmäßige Prüfung der verwendeten Abhängigkeiten, Prüfung auf versehentlich veröffentlichte Zugangsdaten und vor allem Tests für alles, was Root-Rechte, Shell-Befehle, Backup & Restore oder Benutzereingaben verarbeitet. Das geht alles super per Github und deine KI kann dich hier sicherlich beraten. Wenn du sowieso KI für praktisch die komplette Entwicklung nutzt, dann lass genau diese KI vor jedem Release nochmal ihren eigenen Mist auseinandernehmen.
Die Geschichte mit dem "öffentlich" Ordner ist für mich eigentlich das perfekte Beispiel. Du hast selbst geschrieben, dass deine KI private und öffentliche Sachen durcheinandergebracht hat. Genau sowas muss dir vor einer Veröffentlichung auffallen und nicht erst, wenn irgendein User zufällig drüber stolpert.
Und die Repo selbst würde ich ehrlich gesagt auch mal etwas aufräumen. HANDBOOK_EN.md, HANDBOOK_EN.pdf, HANDBUCH.md, HANDBUCH.pdf, HANDBUCH_STRUKTURIERT.md, Builder, Installer, Bilder und Anwendungscode alles im Hauptverzeichnis wirkt wie eins der Kinderzimmer meiner Kinder.
Leg dir hier doch einfach Ordner an für docs, src, tests usw., das würde es wesentlich übersichtlicher machen.
Dazu kommen weiterhin Ungereimtheiten in der Dokumentation. Deine README hat z.B. noch auf eine ältere Version verwiesen und im CHANGELOG finden sich Verweise auf Sachen, die im öffentlichen Repo überhaupt nicht vorhanden sind.
Und bitte nicht falsch verstehen: Ich erwarte nicht von dir, dass du jede einzelne Codezeile auswendig kennst, aber wenn man ein Tool veröffentlicht das mit Root Rechten auf dem NAS anderer Leute arbeitet, kann die Lösung meiner Meinung nach nicht sein:
„Ich verstehe nicht alles, was die KI schreibt und teste halt ob es funktioniert.“
Du kannst nicht erst veröffentlichen und dann darauf hoffen, dass irgendwann jemand aus der Community deine Sicherheitsprüfung übernimmt.
Am Ende spielst du mit der Sicherheit und den Daten der Benutzer deines Tools. Die Verantwortung für das, was veröffentlicht wird, liegt bei demjenigen, der auf Release drückt. Und das bist am Ende du und nicht deine KI.
Ich finde dein Engagement für die Community wirklich super und auch die Idee hinter deinem Tool ist klasse, aber bei so weitreichenden Rechten auf einem NAS würde ich persönlich lieber fünf Funktionen weniger haben wollen und dafür wirklich verstehen, testen und absichern, was die vorhandenen Funktionen machen.
Sicherheit geht bei sowas für mich einfach vor. Viele User installieren solche Tools blind, geben ihre NAS Zugangsdaten ein und denken „wird schon passen, was RUNLEVEL da gemacht hat“. Genau deshalb sollte bei einem Admin-Tool Sicherheit immer an erster Stelle stehen. 
