Tester/Mitentwickler für UGOS Apps gesucht

Ich würde dich gerne unterstützen, aber meine Zeit ist derzeit ziemlich knapp. Deshalb kann ich mich vermutlich nicht so intensiv einbringen.

Wenn du öffentlich das Feedback der Tester sammeln möchtest, kannst du hier im Unterforum gerne für jede App einen eigenen Thread anlegen, zum Beispiel mit [BETA] oder "[ENTWICKLUNG] APP-Name" im Titel.

Quote from Runlevel5

Was ich brauche sind Leute mit Entwickler Account

Ich denke du solltest dabei schreiben, dass das bedeutet "hochsensible" Daten an eine chinesische Firma zu übermitteln, da man sich für den Account eingehend identi-/verifizieren muss, wenn ich das richtig gesehen habe.
Da hat es sich bei den meisten hier denke ich sowieso schon direkt erledigt. 😆

Warum genau braucht jeder einen Entwickler-Account? Muss der mit dem Gerät verknüpft werden und nur so kannst du die Testversionen über den offiziellen App-Store zur Verfügung stellen?

Grundsätzlich würde ich mich schon dafür anbieten, da ich Spaß an solchen Dingen habe und auch denke ich nicht ganz auf den Kopf gefallen bin. Und Zeit ist momentan auch da.

Habe aktuell nur eine NAS (siehe Signatur) und kann nicht mit mehreren dienen wie einige andere hier.

Sofern das für dich ausreicht, können wir das gerne angehen.

Ja, so ähnlich hatte ich das ja geschrieben/vermutet. 🙃

Ja, wie gesagt, wenn das sonst für dich passt, können wir da gerne zusammenarbeiten und dann mache ich mir da nen Account.

Servus, kleiner Hinweis von mir, bevor hier noch mehr Leute die App mit SSH- und sudo-Rechten auf ihren NAS testen.

Ich hatte im GitHub-Repo bereits einige aus meiner Sicht ziemlich kritische Sicherheitspunkte gemeldet. Unter anderem fehlende SSH-Host-Key-Prüfung, standardmäßig deaktivierte TLS-Verifikation, Auto-Update ohne zusätzliche Integritätsprüfung und die Speicherung von Zugangsdaten in einer JSON-Datei.

Gerade bei einem Admin-Tool mit so weitreichenden Rechten finde ich das ehrlich gesagt nicht ganz unwichtig.

Auf eine Antwort zu meinem GitHub-Issue warte ich übrigens immer noch.

Immer wieder gerne. Sicherheit geht auf jeden Fall vor, besonders bei so einem Tool, das am Schluss zum Einfallstor ins NAS werden und so die Daten gefährden kann

Sorry, ich bin leider schon genug ausgelastet mit meinen Projekten. Sorry.
Wenn der Tag irgendwann 72 Stunden hat, können wir nochmal drüber reden. 😄
Aber ein paar Stunden Schlaf brauche ich leider auch noch.

Immer wieder gerne
Ich guck mir das später mal genauer an. Aber ich muss dich ehrlich mal fragen: Prüfst du eigentlich nach, was deine KI dort schreibt?

Alleine in deiner README steht:

Quote

This file is the public release README (folder öffentlich/). The step-by-step guide below mirrors the private project's main README.md ...

Den Ordner öffentlich gibt es in der GitHub-Repo überhaupt nicht. Das wirkt auf mich ehrlich gesagt so, als würdest du mit KI Arbeiten, ohne danach nochmals zu prüfen, was überhaupt gemacht wird. Gerade bei einem Tool mit SSH und Root-Zugriff finde ich das sehr gefährlich. Das ist nicht böse gemeint, damit können User unnötig gefährdet werden, die sich blind auf dieses Tool verlassen.

Den Code habe ich auch nur kurz überflogen und dabei direkt noch weitere Sachen gesehen. Zum Beispiel steht in ugos_api_client.py weiterhin:

verify_ssl: bool = False

This image is exclusive to our members!
Please log in or register for free to view graphics and attachments.

Damit ist zumindest der TLS-Punkt nicht vollständig umgesetzt, sondern die Zertifikatsprüfung ist trotzdem ausgeschaltet. Den Rest schaue ich mir später an, wie bereits geschrieben.

Ich finde es wirklich toll, das du dich für die Community so einsetzt, aber eine Sache muss auch klar sein. Sicherheit geht hier einfach vor.

Naja genau das meinte ich eigentlich. Wenn deine KI private und öffentliche Sachen durcheinanderwirft und du selbst schreibst, dass du dir nicht alles durchlesen kannst, was die Kiste reinschreibt, dann ist das bei so einem Tool für mich halt schon ein Problem und sicherheitstechnisch schwierig

Beim Thema TLS geht es auch nicht darum, dass UGOS ein selbstsigniertes Zertifikat nutzt, deswegen muss man nicht die Verifizierung abschalten. Das eigentliche Problem ist verify_ssl=False. Die Verbindung kann damit zwar verschlüsselt sein, aber die Gegenstelle wird eben nicht geprüft und somit weißt du im Zweifel nicht sicher, mit wem du da gerade sprichst.

Das ist ja nur ein Thema. Wenn ich mir später deinen Code weiter anschaue bin ich gespannt, was sich noch so auftut. Bei einem Tool, das per SSH und mit Root Rechten auf dem NAS arbeitet, finde ich sowas einfach schwierig, wenn du die verschiedenen Optionen im Code nicht verstehst oder prüfst.

Ich würde da ehrlich gesagt lieber eine Funktion weniger einbauen und dafür wirklich verstehen und prüfen, was den der Code überhaupt macht.

Nicht, dass du mich falsch verstehst: Ich finde es wirklich toll, dass du dich so für die Community einsetzt und so etwas in deiner Freizeit baust. Aber gerade bei so einem Tool musst du meiner Meinung nach auch wissen, was dein Code im Hintergrund macht. Wenn du das nicht weißt, wird es irgendwann schwierig und potentiell gefährlich für jeden, der das Tool nutzt.

Ist wirklich nicht böse gemeint, aber Sicherheit geht bei sowas für mich einfach vor. Viele User installieren solche Tools einfach blind, auch weil sie davon ausgehen, dass das schon sicher sein wird. Genau deshalb finde ich auch, dass man hier bei so einem Tool lieber einmal mehr hinschauen sollte, als einmal zuwenig.

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.

Quote from RomanG

Die größten Baustellen sind:

Siehe meine offenen PRs.

Ich möchte generell zu dem Thema noch etwas ergänzen, weil ich das Gefühl habe, dass das hier sonst wieder als KI-Hate/-Scare aufgenommen werden könnte.

Ich bin selbst ein großer Verfechter von KI und finde, dass es in diversesten Situationen und Bereichen eine massive Erleichterung, Qualitätssteigerung und Hilfe sein kann und auch ist...

...sofern man es richtig bedient und sich vernünftig damit beschäftigt. Und da scheitert es bei den meisten mMn.

Ich sehe KI immer wie einen Mitarbeiter in einer Firma:

- Gebe ich ihm keine klaren Aufgaben und Instruktionen (oder sogar missverständliche), ist das Ergebnis seiner Arbeit meistens entsprechend minderwertig
- Ich muss mich mit meinem Mitarbeiter beschäftigen und auch seine Eigenheiten kennen, um sein Potenzial entfalten zu können. Ich muss wissen wie er ungefähr denkt, wie er reagiert, welche Worte ich nutzen muss, ...
- Einen "weniger intelligenten" oder "fachlich nicht qualifizierten" Mitarbeiter sollte ich vielleicht nicht Adminzugriff auf die IT-Systeme geben oder ihn die Bilanz durchführen lassen

Was meine ich damit?
- Obwohl intelligente KI (ja es gibt auch weniger intelligente) tatsächlich mittlerweile sogar ziemlich gut darin ist User-Instruktionen mit Kontext zu verbinden und zu erweitern und somit auch unklare Instruktionen recht gut zu verstehen, ist das immer noch ein wichtiger Teil. Es gibt nicht umsonst den Begriff und das Feld "Prompt-Engineering"
- Es herrscht oft der Irrglaube, dass ich von einem Fach (z.B. jetzt IT und Programmieren) absolut gar nichts wissen muss und eben KI alles machen lassen kann. Fakt ist aber, dass ich für alles was über ein simples Backupskript in Powershell oder eine kleine Webseite hinaus geht, doch schon ein Grundverständnis für die Materie haben muss, um überhaupt eben den Punkt "klare Instruktionen" bieten zu können und vor allem auch beim Arbeitsprozess der KI und dem Endergebnis beurteilen kann, ob das was da passiert ist zumindest im groben korrekt ist
- Ich denke viele beschäftigen sich nicht wirklich mit den heutzutage leider immer noch üblichen verschiedenen Intelligenz-/Denkstufen einer KI bzw. unterschätzen diese oder wollen Kosten sparen ohne einschätzen zu können, welche Stufe für was geeignet ist. Abgesehen davon, dass ich noch nie ein Fan von Claude war und Codex nutze, lasse ich dort nie etwas unter der Stufe "Sehr hoch" programmieren oder reviewen. Schon gar nicht, wenn das Thema Sicherheit ins Spiel kommt und gerade da ist zumindest Codex bereits SELBST immer sehr bedacht drauf, auch wenn ich es nicht explizit angebe (so zumindest meine bisherige Erfahrung). Es ist ein massiver Unterschied, ob ich z.B. mit "Mittel" oder eben "Sehr hoch" programmieren lasse. Grundsätzlich gilt da: je niedriger das Reasoning, desto exakter muss mein "Pflichtenheft" sein. Das ist wie in der realen Welt der Unterschied, ob ich einen reinen Coder angestellt habe, der einfach nur ein Pflichtenheft runterschreibt oder einen renommierten Full-Stack-Entwickler der auch über den Tellerrand hinaus schauen kann


TL;DR:
Die meisten verstehen KI nicht und verteufeln sie deswegen ohne sich genauer damit zu beschäftigen.