Nutzer bestaetigte "funktioniert". Gitea-Issue #25 angelegt und
geschlossen, Status in bugs.md/found.md auf live bestaetigt aktualisiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SSHTransport.connect()/run() hatten keinen Timeout - im Gegensatz zu
RestTransport (timeoutInterval=5). Jeder erste Schreibvorgang einer
Session loest ueber ensureSessionBackup() eine dedizierte SSH-
Verbindung aus; haengt die, blieb isApplying unbegrenzt aktiv (kein
Fehler, kein Recovery, nur Force-Quit). Live vom Nutzer bestaetigt
(Experte-Tab, dauerhaft haengend) bevor der Fix geschrieben wurde.
Neuer genererischer SSHTransport.withTimeout(_:operation:) (Task-
Group-Race gegen eine Deadline), angewendet auf connect() (10s) und
run() (30s). 3 neue Regressionstests fuer die Race-Logik isoliert.
Nebenbefund: xcodegen generate ueberschreibt Info.plist komplett aus
project.yml (kein Merge) - ein Regenerieren fuer die neue Testdatei
setzte die Version stillschweigend von 1.1.0 auf 1.0 zurueck. Version
jetzt explizit in project.yml verankert.
Build + alle 106 Unit-Tests gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Eintrag #11: Nutzer-Meldung + Code-Audit-Befund (plausibler
Kandidat: SSHTransport.connect() hat keinen Timeout, jeder erste
Schreibvorgang pro Session loest ueber ensureSessionBackup() eine
dedizierte SSH-Verbindung aus - haengt die, blockiert die UI
unbegrenzt). Noch nicht bestaetigt, Status offen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bisher wirkten die neuen Firewall-Isolationsregeln nur auf neue
Verbindungen - eine bereits offene Verbindung zwischen zwei gerade
isolierten Netzen lief unbeeinflusst weiter (Standard-Verhalten jeder
stateful Firewall). Neue SSHTransport.flushConnections/
ConnectionService.flushConnections entfernen per /ip firewall
connection remove [find where (src-address in A) and (dst-address in
B)] bereits getrackte Verbindungen zwischen isolierten Netzpaaren,
aufgerufen direkt nach den Firewall-Befehlen in SetupViewModel.apply().
FirewallConfig.NetworkSegment um networkAddress (CIDR) erweitert,
Paar-Logik in eine wiederverwendbare isolatedNetworkPairs-Property
extrahiert. networkA/networkB werden vor der SSH-Interpolation als
reine CIDR-Notation validiert (dieselbe Vorsicht wie bei der zuvor
gefixten CLI-Injection).
Ehrlicher Verifikationsstand dokumentiert statt Überclaiming: die
kombinierte remove-Bedingung ließ sich mangels zweier echter
Testnetze nicht end-to-end beweisen - ein erster scheinbarer Erfolg
stellte sich als Messfehler heraus (natürlicher ICMP-Conntrack-Timeout,
nicht der remove-Befehl selbst). Details in bugs.md #7.
Build + alle 103 Unit-Tests grün (1 neuer Regressionstest).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Alle 20 granularen Funde aus found.md (#1-10) und bugs.md (#1-10) als
einzelne Gitea-Issues angelegt (#3-22): 19 direkt geschlossen (Status
laut Doku "fixed"), 1 offen gelassen (bugs.md #7, Firewall-Isolation-
Beobachtung, bewusst ohne automatischen Fix). Jeder Markdown-Eintrag
verweist jetzt per Link auf sein Gitea-Issue.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
README-Milestone-Nachcheck (Port-Konflikt-Prüfung/"Fertig"-Button)
deckte drei eigenständige Bugs derselben Klasse auf: Cancel/OK-Buttons
bei ReviewApplyViews Apply-Fehler-Alert, ConnectViews
Zertifikat-Alert und ConnectViews SSH-Hostkey-Alert taten nichts oder
zu wenig - der jeweilige Verbindungs-/Fehlerzustand blieb hängen,
der Dialog konnte nicht sauber verlassen werden.
Neue ConnectionService.cancelPendingTrustConfirmation() und
SetupViewModel.dismissApplyError(), alle drei Alerts korrekt
verdrahtet (Button-Action + Bindings-Setter fuer Tap-Outside/Esc).
Totes dismissPendingSSHTrust() entfernt. 1 neuer Regressionstest,
alle 102 Unit-Tests gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dritter, sicherheitsfokussierter Deep-Dive-Durchgang ("maximale Sicherheit"):
- RestTransport.fetchFieldValues hatte dieselbe ungeschützte
String-Interpolation wie das SSH-Pendant aus dem vorigen Fix, nur als
URL-Query statt CLI-Zeile - beim ersten Fix übersehen. Jetzt
RFC-3986-konform percent-encoded.
- CertificateFingerprint.sha256 fiel bei Extraktionsfehlern auf einen
festen String "unbekannt" zurück statt echtem Fingerabdruck -
theoretisches TOFU-Pinning-Bypass-Fenster (zwei verschiedene,
extraktions-fehlschlagende Zertifikate hätten sich denselben
"Fingerabdruck" geteilt). Rückgabetyp optional, Extraktionsfehler
führt jetzt zu hartem Verbindungsabbruch statt Trust-Dialog.
Beide Fixes defensiv/gehärtet, nicht live exploitiert. Zugangsdaten-
Speicherung (Keychain) und BackupServices eigene Escaping-Logik
gegengeprüft - bereits korrekt. Build + alle 101 Unit-Tests grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Deep-Dive-Gegencheck mit echtem Exploit-Nachweis gegen den Testrouter:
- RouterOSCommand.cliLine quotete Werte nur bei Leerzeichen und escapte
eingebettete Anführungszeichen nie. Ein Kommentar wie test" ; :log
warning "X schloss das Quoting vorzeitig und ließ RouterOS den Rest
als zweiten Befehl ausführen. Live exploitiert (injizierter
script,warning-Log-Eintrag) und live als behoben bestätigt. Betraf
jede Schreiboperation über SSH - auf dem aktuellen Testrouter ist
www-ssl deaktiviert, REST also unerreichbar, der Bug war aktiv.
- RouterOSCliParser.keyValues nahm an, print terse quote mehrwortige
Werte - live an zwei Menüs widerlegt (RouterOS 7.24.4 quotet dort
nichts). Trunkierte jeden mehrwortigen Wert beim ersten Leerzeichen.
Fix: Token-Scan statt Regex.
- SSHTransport.fetchFieldValues defensiv gegen dieselbe Injection-Klasse
gehärtet (aktuell nur hartkodiert aufgerufen, aber generische API).
2 neue Regressionstests, alle 101 Unit-Tests grün. Details in bugs.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Race Condition bei LAN-Port-Konflikt-Prüfung (Generation-Zähler), Firewall-Titel
widersprach sich im Einfach-Modus, 2 fehlende EN-Übersetzungen, Health-Check-
Herzschlag ignorierte laufende Wizard-/Experte-Schreibvorgänge. Außerdem M7/M9
im README/HANDOFF auf fertig aktualisiert (Modusschalter+Experte-Zweig liefen
bereits über die Multi-LAN/WLAN-Live-Tests).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
