DanSandClaude Opus 5.5
eac0993512
The Lite "Encrypt wallet" field and the Create/Restore passphrase had no confirmation and no minimum length; only an empty passphrase was refused. Encrypting locks the wallet at once, and a locked wallet cannot reveal its seed, so a typo there could cost a user without a seed backup their funds. The full-node encrypt dialog already requires 8 characters and a confirmation. This applies to new passphrases only. Opening and unlocking are unchanged: an existing wallet with a shorter passphrase still opens and unlocks. - A pure liteEncryptPassphraseValid(pass, confirm): at least 8 bytes and equal to the confirmation. It takes string_views, so the page's secret buffers are never copied. - liteLifecyclePassphraseAcceptable(op, pass, confirm) gates the Settings create/open/restore request. Open is never checked, because its passphrase field also unlocks an existing wallet. Create and Restore are checked only when a passphrase was entered; an empty one still creates an unencrypted wallet. - Encrypt gets a Confirm field. The button stays disabled until the passphrase is valid, and a hint says why (too short, with the count, or not matching). - Create/Restore show a Confirm row once a passphrase is typed, with the same hint. Validate stays disabled while the passphrase is invalid, so a click never wipes a typed seed over a passphrase typo. The request builder re-checks the rule. - The confirmation buffers are wiped with their passphrase: after a run or an encrypt, and when the Confirm row is hidden. - Once the wallet is closed, the Settings page wipes the Encrypt, Confirm and Decrypt passphrase buffers whole every time, also when no secret was revealed; before, closing the wallet wiped them only while clearing a revealed backup or secret. They are zeroed in full because an emptied field can still hold the old tail past its first NUL. - New copy under Encrypt: "Anyone with the wallet file can try passphrases offline. Back up your seed phrase first and use a long passphrase." - i18n: three new keys (lite_confirm_label, tt_lite_confirm_pass, lite_encrypt_offline_warning) in i18n.cpp and the 8 language files, added additively. The hints reuse the wizard's wiz_pass_too_short and wiz_pass_mismatch. No new CJK glyphs, so the subset font is unchanged. Tests: the validator rejects empty, short (7) and mismatched or unconfirmed passphrases, and accepts 8 or more with a match. The request gate always accepts Open, even "abc" with no confirmation, accepts Create/Restore without a passphrase, and applies the rule to them otherwise. An encrypted, locked wallet still opens and unlocks through the controller with the 3-character passphrase "abc". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
27 lines
1.0 KiB
C++
27 lines
1.0 KiB
C++
#include "lite_wallet_lifecycle_ui_adapter.h"
|
|
|
|
// The lite-wallet lifecycle UI adapter declares the live LiteWalletLifecycleUiExecutionInput DTO
|
|
// (and its request-intent / prerequisites sub-structs) that Settings drives the App-owned
|
|
// controller with. The former dry-run "readiness" executor and its status/issue reporting were
|
|
// removed as dead scaffolding. The only out-of-line definitions here are the pure passphrase rules
|
|
// Settings applies to NEW passphrases.
|
|
|
|
namespace dragonx {
|
|
namespace wallet {
|
|
|
|
bool liteEncryptPassphraseValid(std::string_view pass, std::string_view confirm)
|
|
{
|
|
return pass.size() >= kLiteMinNewPassphraseLength && pass == confirm;
|
|
}
|
|
|
|
bool liteLifecyclePassphraseAcceptable(LiteWalletLifecycleOperation operation,
|
|
std::string_view pass, std::string_view confirm)
|
|
{
|
|
if (operation == LiteWalletLifecycleOperation::OpenExisting) return true;
|
|
if (pass.empty()) return true;
|
|
return liteEncryptPassphraseValid(pass, confirm);
|
|
}
|
|
|
|
} // namespace wallet
|
|
} // namespace dragonx
|