Context
Follow-up zu #485. Bewusst aus dem PR-Scope gehalten — pre-existing scope gap, sauber im PR-Body dokumentiert.
Issue
lib/screens/create_wallet/bloc/create_wallet_cubit.dart (Cubit-State)
Während Wallet-Erstellung (Create-/VerifySeed-Flow) lebt die Mnemonic im CreateWalletState.wallet (Cubit-State), nicht im AppStore.wallet. Der in #485 eingeführte WalletService.lockCurrentWallet() no-op't deshalb auf diesem Pfad (Guard if (!isWalletLoaded) return greift).
Threat
Der eigentliche Mnemonic-Generation-Moment im Onboarding ist genau der Augenblick, wo die Mnemonic frisch erzeugt und am verwundbarsten ist. Wenn der User die App in diesem Fenster in den Hintergrund schiebt (z. B. weil ein Anruf reinkommt), und iOS den Isolate suspendiert, persistiert die Mnemonic in einem Snapshot.
Vorgeschlagener Fix
Zwei Optionen:
A. Cubit-Listener: CreateWalletCubit bekommt einen eigenen AppLifecycleListener und cleart bei hidden den State (emit(initial)) oder navigiert zurück zum Onboarding-Start. Vorteil: minimaler Eingriff, Cubit bleibt Owner seines States.
B. Zentralisieren: WalletService bekommt einen optionalen Cleanup-Hook, an dem sich der CreateWalletCubit registriert. _onHidden ruft beide Pfade an. Vorteil: ein zentraler Lifecycle-Punkt; Nachteil: zusätzliche Indirektion.
Empfehlung: A für die Mindest-Lösung. Plus Widget-/Cubit-Test, der die Sequenz "Cubit hat Mnemonic → AppLifecycleState.hidden → Cubit-State ist gecleared" pinnt.
Severity
Info / low — User-getriebenes Zeitfenster, kein automatischer Trigger. Aber semantisch unverbundene Schwester von #485: dort wurde der Threat für geladene Wallets geschlossen, hier bleibt er für frisch erzeugte Wallets offen.
Siehe #488 für die verwandte Race im geladenen Wallet-Pfad.
Context
Follow-up zu #485. Bewusst aus dem PR-Scope gehalten — pre-existing scope gap, sauber im PR-Body dokumentiert.
Issue
lib/screens/create_wallet/bloc/create_wallet_cubit.dart(Cubit-State)Während Wallet-Erstellung (Create-/VerifySeed-Flow) lebt die Mnemonic im
CreateWalletState.wallet(Cubit-State), nicht imAppStore.wallet. Der in #485 eingeführteWalletService.lockCurrentWallet()no-op't deshalb auf diesem Pfad (Guardif (!isWalletLoaded) returngreift).Threat
Der eigentliche Mnemonic-Generation-Moment im Onboarding ist genau der Augenblick, wo die Mnemonic frisch erzeugt und am verwundbarsten ist. Wenn der User die App in diesem Fenster in den Hintergrund schiebt (z. B. weil ein Anruf reinkommt), und iOS den Isolate suspendiert, persistiert die Mnemonic in einem Snapshot.
Vorgeschlagener Fix
Zwei Optionen:
A. Cubit-Listener:
CreateWalletCubitbekommt einen eigenenAppLifecycleListenerund cleart beihiddenden State (emit(initial)) oder navigiert zurück zum Onboarding-Start. Vorteil: minimaler Eingriff, Cubit bleibt Owner seines States.B. Zentralisieren:
WalletServicebekommt einen optionalen Cleanup-Hook, an dem sich derCreateWalletCubitregistriert._onHiddenruft beide Pfade an. Vorteil: ein zentraler Lifecycle-Punkt; Nachteil: zusätzliche Indirektion.Empfehlung: A für die Mindest-Lösung. Plus Widget-/Cubit-Test, der die Sequenz "Cubit hat Mnemonic → AppLifecycleState.hidden → Cubit-State ist gecleared" pinnt.
Severity
Info / low — User-getriebenes Zeitfenster, kein automatischer Trigger. Aber semantisch unverbundene Schwester von #485: dort wurde der Threat für geladene Wallets geschlossen, hier bleibt er für frisch erzeugte Wallets offen.
Siehe #488 für die verwandte Race im geladenen Wallet-Pfad.