Deep Analysis 2026-06-04 — teddytafforge-proxmox #9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Deep Analysis 2026-06-04 — teddytafforge-proxmox
Autonome Multi-Agent-Analyse (Recon + 5 Blickrichtungen + adversariale Verifikation). Stand 2026-06-04.
1. Ueberblick & Einordnung
full— reiner Bash/POSIX-sh Installations-Wrapper, kein Anwendungscode..taf-Builder) und optional TeddyCloud als unprivilegierter Debian-13-LXC auf Proxmox VE. Topologien:sidecar(TC extern, mp0-Bind-Mount) undall-in-one(TC nativ im selben LXC gebaut).ct/teddytafforge.sh→misc/build.func(+install.func) → In-LXC-Installerinstall/*.sh→ verbatim vendored Upstream-Installervendor/tafforge-install/. systemd-Units, whiptail-Dialoge, DRY_RUN-Matrix-Dry-Test, 3-stufige Forgejo-CI (shellcheck/bashate,bash -n, Drift-Probe + URL-Liveness).pct-Argumente via Bash-Arrays (keine Command-Injection), Eingabe-Validatoren, ERR-Traps mit Stack-Trace, Rollback-Traps fuer halb-gebaute LXCs, gehaertete TafForge-systemd-Unit.Wichtige Drift-Korrektur (alle 5 Agenten bestaetigt + adversarial verifiziert): Der lokale Klon steht auf Branch
fix/followup-2026-05-28(HEAD5799d17= offener PR #7), nicht aufmain(aad7f31).git merge-base --is-ancestor 5799d17 origin/main=> NEIN. Der Versions-Pinv0.2.2existiert nur im PR-Branch;origin/maintraegt weiterhin den mutablemain-Ref (verifiziert viagit show origin/main:). Wer das public Repo percurl|bashnutzt, zieht den ungepinnten Stand. Befunde sind daher gegenorigin/mainals Ground-Truth formuliert.2. Gesamtbewertung
Health-Grade: B
Strukturell sauberes, sorgfaeltig gebautes Wrapper-Repo mit guter Defensive (Array-basierte
pct-Aufrufe, Traps, Validatoren, gehaertete TafForge-Unit, Matrix-Dry-Test, mehrstufige CI). Keine committeten Secrets (.claude/settings.local.json= 0 Bytes;.gitignoredeckt.env/*.key/*.pem). Die offenen Punkte sind real, aber begrenzt: das dominierende Thema ist das Supply-Chain-/Ausfuehrungsmodell (curl|bashals root ohne Integritaetspruefung + mutable App-Ref aufmain), dazu zwei vollstaendig tote IPv6-Pfade und eine Update-Pfad-Regression, die der geplante Tag-Pin (PR #7) einfuehrt. Kein einzelnes Critical. B statt A wegen der ungeloesten Supply-Chain-Lage und der Tatsache, dass der einzige fertige Fix (PR #7) seit 2026-05-29 ungemergt haengt — und so wie er ist den Updater bricht.3. Bugs & Korrektheit
[MEDIUM]
git pull --ff-onlywird nach Tag-Klon zum stillen No-Op — Update-Pfad bricht durch den v0.2.2-Pin —vendor/tafforge-install/lxc/update-app.sh:50-52,install/teddytafforge-install.sh:41,83-86— Der In-LXC-Installer klont die App mitgit clone --depth=1 --branch "${TAFFORGE_REF}"und kopiert.gitnach${APP_DIR}/.git, damitupdate-app.shden git-Pfad nimmt. SobaldTAFFORGE_REFein Tag ist (PR #7:v0.2.2), erzeugt der Tag-Klon einen detached HEAD ohne Tracking-Branch;git pull --ff-onlymeldet dann immer „Bereits aktuell" bzw. schlaegt fehl — der App-Code bleibt fuer immer aufv0.2.2, nur pip/npm laufen. Aufmain(Branch-Klon) funktioniert der Updater; der Tag-Pin aus PR #7 fuehrt die Regression erst ein. Empfehlung:update-app.shref-bewusst machen — bei detached/Tag-Checkoutgit fetch origin "$APP_REPO_REF" && git checkout "$APP_REPO_REF"statt blindempull --ff-only; mindestens detached HEAD erkennen und ehrlich melden statt stillem No-Op. (Voraussetzung bevor PR #7 / Tag-Pins ausgeliefert werden; bezieht sich auf #3 / PR #7.)[MEDIUM]
disable_ipv6()ist toter Code — wird nie aufgerufen —misc/install.func:47-54— Die Funktion schreibt per sysctl/etc/sysctl.d/99-disable-ipv6.conf, wennDISABLE_IPV6=yes, wird aber in keinem Skript der Kette aufgerufen (grep -rn 'disable_ipv6'zeigt nur die Definition). Die whiptail-Frage „Disable IPv6 in the LXC? (Recommended on networks without IPv6 to avoid apt hangs.)" (build.func:354) suggeriert eine In-LXC-IPv6-Abschaltung, die faktisch nie passiert —DISABLE_IPV6wirkt nur aufbuild.func:525(,ip6=autoimnet_argweglassen), was den IPv6-Stack im LXC nicht deaktiviert; der versprochene apt-Hang-Schutz greift nicht. Empfehlung:disable_ipv6insetting_up_container()(oder am Anfang der In-LXC-Installer) aufrufen ODER Funktion + irrefuehrende Dialogzusage entfernen.[LOW]
DISABLE_IPV6wird nicht an den In-LXC-Installer durchgereicht —misc/build.func:605-616,misc/install.func:48— Selbst wenndisable_ipv6()verdrahtet waere, koennte es nie greifen: derpct exec ... -- env-Block (605-616) listetDISABLE_IPV6nicht auf. Die In-LXC-Skripte sehen die Variable nie;${DISABLE_IPV6:-no}wertet immer zuno. Zwei unabhaengige Defekte (nie aufgerufen + nie uebergeben) sorgen gemeinsam dafuer, dass die In-LXC-Abschaltung unter keinen Umstaenden laeuft. Empfehlung:DISABLE_IPV6="$DISABLE_IPV6"in denpct exec env-Block aufnehmen (zusammen mit dem Aufruf aus dem vorigen Finding).[LOW] Sidecar-Update re-templatet das Plugin auf den all-in-one-Default-Pfad —
vendor/tafforge-install/lxc/update-app.sh:87,tafforge.env.sample:17,20,misc/build.func:417—update-app.shruftinstall-plugin.shmit"${PLUGIN_ROOT:-/opt/teddycloud/data/www/plugins}"(all-in-one-Layout). Im Sidecar liegt das Ziel unter dem mp0-Mount (Default/mnt/teddycloud-data/.../plugins).PLUGIN_ROOTist intafforge.env.sampleauskommentiert,TEDDYCLOUD_DATA_DIR=/opt/teddycloud/datafest gesetzt; beim Sidecar-Update wirdPLUGIN_ROOTnicht gesetzt → Default greift →install-plugin.shlaeuft gegen einen im Sidecar nicht existierenden Pfad und ueberspringt (per|| true, kein Abbruch) die Aktualisierung. Erstinstallation ist korrekt (Wrapper uebergibt dort den mp0-Pfad); nur der spaetere Update-Lauf verliert diesen Kontext. Empfehlung: Bei Wrapper-Installs den real gewaehlten mp0-Pfad alsPLUGIN_ROOT/TEDDYCLOUD_DATA_DIRin/etc/tafforge/tafforge.envpersistieren, oder inupdate-app.shaus/etc/tafforge/proxmox.metaableiten.[LOW]
valid_ipv4/valid_cidrakzeptieren 5+ Oktette (z.B.1.2.3.4.5) —misc/build.func:216,223— Beide nutzenIFS=. read -r a b c d _ <<< "$addr"und pruefen nur[ -n "$d" ]. Ein fuenftes Feld landet in_und wird nicht zurueckgewiesen. Empirisch reproduziert:valid_ipv4 '1.2.3.4.5'=> return 0,valid_cidr '1.2.3.4.5/24'=> return 0; zu kurze Adressen (1.2.3) werden korrekt abgewiesen, zu lange nicht. Geringe Auswirkung (Wert geht inpct ... ip=, das selbst validiert), aber die Validierungsfunktion erfuellt ihren Zweck nicht vollstaendig. Empfehlung: Trailing-Feld pruefen:IFS=. read -r a b c d e <<< "$addr"; [ -n "$d" ] && [ -z "$e" ] || return 1.4. Security
[HIGH] Mehrstufiges
curl|bash/source <(curl …)als root ohne Integritaetspruefung (keine Checksum/Signatur/Commit-Pin) —ct/teddytafforge.sh:15,19,misc/build.func:605-616,install/all-in-one-install.sh:14,37,41,install/teddycloud-install.sh— Jede Installer-Ebene bootstrappt fremden Code ohne GPG-Signatur, sha256-Vergleich oder Commit-Pinning.REPO_RAW_BASEzeigt hartkodiert auf/raw/branch/main(beweglicher Branch).build.funclaeuft nachroot_checkals root und fuehrt viapct exec ... bash -c "curl … | bash"weiteren Code in der LXC aus; TLS schuetzt nur den Transport, nicht die Integritaet des Inhalts. Eine Kompromittierung von Forgejo/GitHub, ein boesartiger Commit/PR-Merge oder eine TLS-Interception (rogue CA) ergibt root-Codeausfuehrung auf dem PVE-Host. Status: als Forgejo-Issue #2 getrackt, am 2026-05-29 als bewusste Operator-Risikoakzeptanz geschlossen (Repo hat keine Tags / keine Release-Pipeline). Teil-Minderung vorhanden: README enthaelt eine „Paranoid alternative" (download →less→ run,README.md:35-36) und einen „security trade-off"-Hinweis (README.md:225) — entgegen einem Agenten-Befund existiert ein Inspect-Pfad. Es fehlt aber weiterhin jede Pin-/Checksum-/Signatur-Massnahme. Empfehlung:REPO_RAW_BASEauf einen unveraenderlichen Ref (Tag/Commit-SHA) pinnen und per-curl-Artefakte gegen ein eingechecktes sha256-Manifest/Signatur verifizieren; Release-/Tag-Prozess fuer das Wrapper-Repo etablieren. (Bereits getrackt als #2 — Restrisiko bleibt; nicht als neu darstellen.)[HIGH] Default-Branch
mainklont die TafForge-App weiterhin vom beweglichenmain-Ref (mutable Supply-Chain-Ref) —misc/build.func:24(origin/main),install/teddytafforge-install.sh:21(origin/main),vendor/tafforge-install/lxc/install.sh(git reset --hard origin/$APP_REPO_REF),update-app.sh:52— Die App laeuft als (Service-User-)uvicorn-systemd-Dienst und wird pergit clone --branch "${TAFFORGE_REF}"geklont. Auforigin/mainverifiziert:TAFFORGE_REF_DEFAULT="${TAFFORGE_REF_DEFAULT:-main}"(build.func:24) undTAFFORGE_REF="${TAFFORGE_REF:-main}"(teddytafforge-install.sh:21). Der Pinv0.2.2existiert nur im offenen PR #7 (Closes #3,mergeable=true), ist also nicht ausgeliefert. TeddyCloud ist dagegen auf Tagtc_v0.6.8gepinnt (build.func:26) — die Inkonsistenz unterstreicht die fehlende App-Pinnung. Empfehlung: PR #7 nachmainmergen — aber erst nach dem Update-Pfad-Fix (Finding 3.1), sonst tauscht man den mutable Ref gegen einen toten Updater; zusaetzlich den geklonten Tree gegen einen erwarteten Commit-SHA verifizieren. (Bezieht sich auf Issue #3 / PR #7.)[MEDIUM] TafForge-Web-UI bindet auf
0.0.0.0:${TAFFORGE_PORT}(Default 3000) ohne vom Wrapper eingerichtete Authentifizierung —vendor/tafforge-install/lxc/tafforge.service:13,vendor/tafforge-install/lib/env-defaults.sh:19,31,37,misc/build.func:641— Die systemd-Unit startet uvicorn mit--host 0.0.0.0; der Wrapper richtet keinerlei Auth, Reverse-Proxy-Auth oder Firewall ein und bewirbt die UI offen unterhttp://<lxc-ip>:3000/. TafForge bietet Datei-Upload (MAX_UPLOAD_BYTES=2 GiB) und yt-dlp-Outbound-Fetch (ALLOW_NON_YOUTUBE_SOURCES=trueper Default) — d.h. ein per Default LAN-weit erreichbarer Dienst mit Upload-/Fetch-Oberflaeche. Ob die App selbst AuthN/AuthZ hat, ist hier nicht pruefbar (App-Code liegt extern im GitHub-Mirror). Empfehlung: Im README klar dokumentieren, dass der Dienst ohne Auth LAN-weit erreichbar ist und hinter authentifizierenden Reverse-Proxy/VPN gehoert; optional127.0.0.1-Bind bzw. konfigurierbares Bind-Interface als sicherere Default-Variante undALLOW_NON_YOUTUBE_SOURCES-Default ueberdenken.[MEDIUM] TeddyCloud-Dienst laeuft als root ohne systemd-Hardening; Hardening-Gefaelle gegenueber der TafForge-Unit —
install/teddycloud-install.sh:120-136,:73,:143— Im all-in-one-Pfad wird TeddyCloud nativ als root gebaut (make … zip) und die erzeugteteddycloud.servicelaeuft ohneUser=/Group=und ohne jeglicheProtect*/NoNewPrivileges-Direktiven (= root), waehrendtafforge.servicevorbildlich gehaertet ist (User=tafforge,NoNewPrivileges,ProtectSystem=strict,ProtectHome,PrivateTmp…). TC bindet Admin-Ports 80/443/8443 ohne Wrapper-seitiges Auth/Firewalling. Mitigiert durch den unprivilegierten LXC (build.func--unprivileged 1) — ein root-Kompromiss im Container ist nicht automatisch root auf dem Host. Empfehlung:teddycloud.servicemindestens mitNoNewPrivileges=true,ProtectHome,PrivateTmpversehen; falls TC einen Service-User toleriert,User=+ReadWritePathssetzen undAmbientCapabilities=CAP_NET_BIND_SERVICEstatt vollem root fuer Ports <1024. Im README dokumentieren, dass TC-Admin ohne Auth erreichbar ist.[LOW] TEMP-Debug/xtrace-Block schreibt Trace nach vorhersehbarem
/tmp-Pfad (keinmktemp) —misc/build.func:48-53,603,ct/teddytafforge.sh:23-29— MitDEBUG=1wird ein vollerbash -x-Trace nach/tmp/teddytafforge-trace-$$.loggeschrieben;build.func:603legt zusaetzlich/tmp/tafforge-install-${CTID}.logohne explizite Permissions/mktempan. Pfade sind vorhersehbar (PID/CTID), was auf einem Mehrbenutzer-PVE-Host theoretisch Symlink-Risiken erlaubt; praktisch laeuft der Host-Teil nur als root und der Trace nutzt einen dedizierten FD 19. Je nach ENV-Werten koennen Betriebsdaten in den/tmp-Log gelangen. Empfehlung: Block vor breiter Auslieferung entfernen (von den Autoren selbst als TEMP markiert) oder hinter explizites Opt-in mitinstall -m 0600/mktemp-Log absichern.5. Features & QOL
[MEDIUM] CI lintet
vendor/undscripts/nicht — der groesste Teil des als root laufenden Codes ist ungelintet —.forgejo/workflows/shellcheck.yml:24,33,37—shellcheck/bash -ndecken nurct/*.sh install/*.sh misc/*.funcab. Von 17 Shell-Dateien werden 9 nicht geprueft: alle 7 untervendor/tafforge-install/(inkl. der komplexen, als root im LXC laufendenlxc/install.sh) plusscripts/dry-test/{run.sh,matrix.sh}. Ein Quoting-/set -e-Regressionsfehler beim naechsten vendor-Refresh wuerde von der CI nicht erkannt; der Drift-Probe-Step prueft nur env-Var-Namen, nicht die Shell-Korrektheit. Empfehlung: Lint-Targets umvendor/**/*.shundscripts/**/*.sherweitern (ggf. mit tolerantem Disable-Set, da vendor verbatim von upstream kommt — z.B. nurbash -n+ ausgewaehlte SC-Codes).[LOW] Kein post-install Diagnose-/Status-Tool (
ct/doctor.sh) — Troubleshooting nur manuell —README.md:166-177,vendor/tafforge-install/lxc/install.sh(Health-Check nur bei Install),ct/update.sh:30— Nach dem Install gibt es kein Wrapper-Tool, das den Zustand vom PVE-Host aus prueft; der Health-Check laeuft nur einmal bei Erstinstallation.ct/update.shhat bereits die LXC-Erkennung (via/etc/tafforge/proxmox.meta), die fuer einct/doctor.shwiederverwendbar waere. Empfehlung: Schlankesct/doctor.sh(Spiegel zuupdate.sh):systemctl is-active,curl …/api/health, Plugin-Dir/mp0-Mount-Check, TC-Reachability — ein 1-Kommando-Gesundheitsbild ohnepct enter.[LOW] Wrapper-Versionsanzeige fehlt im Header und im LXC-
description-Block —ct/teddytafforge.sh:46,misc/build.func:103-114,642-652—WRAPPER_VERSION(Default0.1.0-dev) wird in/etc/tafforge/proxmox.metageschrieben, aber dem Operator beim Lauf nie angezeigt (weder im ASCII-Header noch imdescription()-Block, derTAFFORGE_REFlistet). Kein--version/-h-Handler im Host-Entrypoint. Beicurl|bashausbranch/mainist die laufende Version sonst nicht erkennbar — relevant fuer Bug-Reports. Empfehlung:WRAPPER_VERSIONim Header-Banner und indescription()ausgeben; optional--version/-h-Kurzhandler.[LOW]
ct/update.shrefresht die vendoredinstall/-Schicht nicht — Drift zwischen App- und Wrapper-Stack —ct/update.sh:49,install/teddytafforge-install.sh:44-60,vendor/tafforge-install/lxc/update-app.sh:50-52—ct/update.shruft nur den In-LXC-update-app.sh(App-Update). Die beim Erstinstall via curl gelegte vendoredinstall/-Schicht (install/lib/*,install/lxc/*) wird beim Update nicht erneuert; verbessert der Wrapper z.B.install-plugin.sh, bekommt eine bestehende Instanz das nie. (Haengt eng mit dem detached-HEAD-No-Op aus Finding 3.1 zusammen.) Empfehlung: Inct/update.shvor dem App-Update die vendoredinstall/lib+install/lxcerneut ausREPO_RAW_BASEziehen;update-app.shref-bewusst machen.[LOW] TafForge-Port und
onbootim Wrapper-Dialog nicht konfigurierbar —misc/build.func:284-365,641,vendor/tafforge-install/lxc/tafforge.service:13— Der whiptail-Flow fragt CTID/Storage/CPU/RAM/Disk/Bridge/IP/MAC/VLAN/MTU/SSH/IPv6/Verbose ab, aber nicht den TafForge-Port (hart3000indescription/Health/Service) oderonboot. DaTAFFORGE_PORTbereits sauber durch die Kette fliesst, waere ein optionaler Dialog billig — relevant bei mehreren Instanzen hinter einem Reverse-Proxy. Empfehlung: OptionalenTAFFORGE_PORT-Dialog ergaenzen, Wert viapct exec envdurchreichen und diedescription()-URL aus dem Port bilden statt der Konstante 3000.[LOW]
teddycloud-install.shueberspringtnetwork_check/setting_up_container/update_os— nur bei direktem Standalone-Aufruf relevant —install/teddycloud-install.sh:31,35,install/all-in-one-install.sh:19-21,misc/install.func(/run/tafforge-prep.done-Gate) — Im normalen all-in-one-Flow ist das korrekt (der Orchestrator macht die Prep einmal, das prep-Gate verhindert Doppel-apt). Aberteddycloud-install.shist via URL-Liveness-CI als eigenstaendigcurl|bash-bar gefuehrt; ein Operator, der nur den TC-Installer direkt aufruft, bekommt keinennetwork_check→ der ersteapt-get update(:35) kann auf einem noch nicht geleasten DHCP-LXC fehlschlagen. Empfehlung: Inteddycloud-install.shnachverbdefensivnetwork_checkaufrufen (durch das prep-Gate im all-in-one-Flow ohnehin No-Op) oder klarstellen, dass der Installer nur ueber all-in-one laufen soll.[LOW] Keine Release-Tags / kein
WRAPPER_VERSION-Bump-Prozess trotz SemVer-Anspruch —README.md:240-247,CHANGELOG.md([Unreleased]),ct/teddytafforge.sh:46— README erklaert SemVer und proxmox.meta-Versionsanzeige; faktisch hat das Reporelease_counter: 0undWRAPPER_VERSIONist hart0.1.0-dev. Fuer einbranch/main-curl|bash-Tool meldet damit jede Instanz0.1.0-devunabhaengig vom Stand. (Voraussetzung fuer den Tag-basierten Pin aus #2/#3.) Empfehlung: Leichten Release-Flow etablieren: Tag setzen,[Unreleased]in eine datierte Version ueberfuehren,WRAPPER_VERSIONaus Tag/CHANGELOG ableiten.6. Struktur, Ordnung, Dateileichen, Templates
[LOW] Veroeffentlichtes Repo ohne Issue-Forms/
config.yamlund ohne committete Issue-/PR-Templates —git ls-tree -r origin/main .forgejo→ nurworkflows/{shellcheck,syntax-validate}.yml— Lokal liegen.forgejo/ISSUE_TEMPLATE/ai-task.mdund.forgejo/PULL_REQUEST_TEMPLATE/ai-pr.md, sind aber via.git/info/exclude:11untracked und damit nie committet. Die Org-Standard-Konvention (config.yamlmitblank_issues_enabled:false+ YAML-Issue-Forms) fehlt aufmain. Empfehlung: Org-config.yaml+ die vorhandenen ai-task/ai-pr-Templates committen (aus.git/info/excludenehmen) oder die Abweichung bewusst dokumentieren.[LOW] Kein zentraler Org-Security-Workflow-Caller (
@v2) —.forgejo/workflows/— Die Workflows sind vollstaendig projekt-spezifisch (shellcheck/bashate/bash -n, Dryrun, README-Link-Check, Drift-Probe); kein Aufruf des org-weiten reusable Security-Workflows (uses: …/ci-workflows…@v2, kein gitleaks/secret-scan-Profil). Fuer ein reines Bash-Repo ohne Dependency-Manifest ist Trivy/SBOM begrenzt wertvoll, aber die fleet-weite Org-Konvention wird hier nicht eingehalten. Empfehlung: Entscheiden, ob ein thin Security-Caller (passendes Bash-Profil: Shellcheck/Hadolint/gitleaks) ergaenzt wird, oder die Abweichung bewusst dokumentieren.[INFO] Fehlende ergaenzende Standarddateien (
CONTRIBUTING.md,SECURITY.md,.editorconfig) —origin/main-Tree — Pflicht-Dateien vorhanden (README, LICENSE=MIT,.gitignore). Fuer ein oeffentliches Repo, dessen Kernfunktioncurl … | bashals root ist, waere eineSECURITY.mdmit Meldekanal + Verifikationshinweis angebracht. Reines Hygiene-Thema. Empfehlung: KnappeSECURITY.md(Meldekanal + curl|bash-Verifikationshinweis); optional.editorconfig(sh: 4 spaces/LF) undCONTRIBUTING/Verweis aufAGENTS.md.[INFO] Als TEMP markierter DEBUG/xtrace-Block weiterhin im Produktiv-Pfad —
misc/build.func:44-61,ct/teddytafforge.sh:23-29,CHANGELOG.md— Explizit markiert „TEMP: remove this section once the install flow is validated on real PVE". DEBUG-gated (Default 0), kein Laufzeit-Risiko im Normalbetrieb, aber als zu entfernender Uebergangscode gekennzeichnet (Follow-up zum geschlossenen Issue #1; kein offener Tracker dafuer). Empfehlung: Entscheidung treffen: nach erfolgter Real-PVE-Validierung entfernen ODER als dauerhaftes Diagnose-Feature entmarkieren und in README/CHANGELOG als stabil fuehren. (Siehe auch Security-Finding 4.5.)7. Status vs. offene Issues & PRs
Offen real (Forgejo, verifiziert): Issues #3 (high, mutable Supply-Chain-Ref) + #8 (Renovate Dependency Dashboard, Bot-managed). PRs #5 (open) + #7 (open).
open_issues_count=2,open_pr_counter=2.fix/followup-2026-05-28, head5799d17, baseaad7f31) — pinntTAFFORGE_REF_DEFAULT/TAFFORGE_REFaufv0.2.2,Closes #3,mergeable=true(kein Konflikt), seit 2026-05-29 unveraendert offen. Verifiziert NICHT auf main (git merge-base --is-ancestor 5799d17 origin/main=> NEIN;origin/main:misc/build.func:24zeigt…:-main). Einziger echter Action-Hebel — aber sollte erst nach dem Update-Pfad-Fix (Finding 3.1) gemergt werden, sonst toter Updater.analysis/findings-2026-05-28, head7f1db72) — reiner Analyse-/Tracking-PR ohne mergebaren Code-Diff, stale. Seine drei High-Punkte sind anderweitig abgehandelt: #4 (gefixt via PR #6, gemergt), #2 (geschlossen als Risikoakzeptanz), #3 (laeuft ueber PR #7). Empfehlung: schliessen (nicht mergen).origin/mainverifiziert:vendor/tafforge-install/lxc/install.sh:230-244captured_WRAPPER_TEDDYCLOUD_DATA_DIR/_WRAPPER_PLUGIN_ROOTvor dem Sourcen vontafforge.envund re-exportiert sie davorPLUGIN_ROOT_RESOLVEDberechnet wird (:250). Kein Handlungsbedarf.README.md:35-36+ trade-off:225), aber es fehlt eine formale Threat-Model-Sektion und jede Checksum/Pin-Massnahme. Restrisiko siehe Security 4.1.description()zeigt dem Operator weiterhinmainals TafForge-Ref (origin/main:misc/build.func:646TafForge ref: ${TAFFORGE_REF_DEFAULT}mit…:-main). Wird mit Merge von PR #7 automatischv0.2.2— erledigt den Operator-Sichtbarkeits-Teil von #3.Drift local↔remote: Lokaler Klon = PR-#7-Head (1 ahead / 1 behind
origin/main); kennt den Renovate-Commitaad7f31/renovate.jsonnicht. Reiner Branch-/Fetch-Drift, kein Code-Konflikt (die divergierenden Dateienrenovate.jsonvs. build.func-Pin ueberschneiden sich nicht → PR #7mergeable=true). Wer den lokalen Klon naiv als Code-Stand liest, sieht faelschlichv0.2.2(gepinnt); produktiv aufmainist esmain(ungepinnt). Bei jeder Statusbewertungorigin/mainals Ground-Truth nehmen.8. Priorisierte Empfehlungen
update-app.sh: detached/Tag →fetch+checkoutstattpull --ff-only), bevor ein Tag-Pin ausgeliefert wirdv0.2.2) — erst nach P1-Update-Fix — schliesst #3 + machtdescription()-Ref korrektREPO_RAW_BASEauf unveraenderlichen Ref pinnen + sha256/Signatur-Verifikation der curl-Artefakte; Release-/Tag-Prozess (auch Voraussetzung fuer WRAPPER_VERSION)disable_ipv6()verdrahten +DISABLE_IPV6impct exec env-Block durchreichen — ODER Funktion+Dialog entfernenteddycloud.servicehaerten (NoNewPrivileges/ProtectHome/PrivateTmp, ggf.User=+CAP_NET_BIND_SERVICE); README: TC-Admin ohne Auth0.0.0.0ohne Wrapper-Auth → Reverse-Proxy/VPN-Hinweis;ALLOW_NON_YOUTUBE_SOURCES-Default ueberdenkenvendor/**/*.sh+scripts/**/*.sherweiternPLUGIN_ROOT/TEDDYCLOUD_DATA_DIRpersistieren, damit Update-Plugin greiftmktemp/0600-Log)ct/doctor.sh, WRAPPER_VERSION-Anzeige, Port-Dialog, vendored-install/-Refresh inct/update.sh,teddycloud-install.shnetwork_checkconfig.yaml/Issue-Forms),SECURITY.mdcommitten9. Methodik & Vertrauensgrad
origin/main+ lokaler PR-Branch + Forgejo-API): der Pin-Drift (git merge-base,git show origin/main:),disable_ipv6tot (grepzeigt nur Definition),DISABLE_IPV6nicht impct exec env-Block, IP-Validator-Bug (empirisch reproduziert:1.2.3.4.5akzeptiert),0.0.0.0-Bind + Hardening-Gefaelle TafForge↔TeddyCloud (Units gelesen),curl|bash-Kette, TEMP-Block, CI-Lint-Coverage, Issue #4-Fix auf main, Forgejo-Issue/PR-Stati (#1–#8), keine committeten Secrets.README.md:35-36(„Paranoid alternative", download→less→run) und:225(trade-off) existieren; es fehlt nur Checksum/Signatur/Pin und eine formale Threat-Model-Sektion. (b) Recon-Annahmen „Pin v0.2.2 ist Code-Stand" / „Renovate fehlt" wurden verworfen — Pin nur in PR #7, Renovate auf main vorhanden. (c) Der TEMP-Block und die Supply-Chain-/mutable-Ref-Punkte tauchten mehrfach auf und wurden je einmal konsolidiert.pct create, In-LXC-Installer-Kette, mp0-Bind, whiptail-TTY-Pfade) — nur via DRY_RUN-Matrix abgedeckt, nicht real ausgefuehrt (OAM-Schutz; keine Builds/Installs/Deploys durchgefuehrt).