When the homeserver advertises custom_recovery_passphrase_settings (and
the enterprise gate is enabled), the secure-backup setup lets the user
enter and confirm their own recovery key with a live strength indicator,
instead of receiving a generated one. The SDK derives the 4S key from the
passphrase and the base58 key is scrubbed everywhere so it is never
shown. Falls back to the generated-key flow when no spec is present or
the well-known fetch fails.
Snapshot PNGs are intentionally left out; the core team regenerates them
after the PR is opened.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
enableRecovery now takes an optional passphrase and returns the recovery
key as the suspend result (like resetRecoveryKey), avoiding the
flow/return-value race. For the passphrase path the SDK-derived base58
key is kept out of the session-scoped progress flow so it is never
surfaced to the user; the caller receives it as the return value and is
responsible for scrubbing it.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add isCustomRecoveryPassphraseEnabled() and
estimateCustomRecoveryPassphraseStrength() to EnterpriseService, plus the
CustomRecoveryPassphraseStrength result types. FOSS builds return
false/null so the feature stays gated off; the enterprise implementation
(estimator) lands separately in the enterprise repo.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add CustomRecoveryPassphraseRequirements to ElementWellKnown and decode
the custom_recovery_passphrase_settings block (currently just
min_character_count) from the homeserver's element.json. Invalid specs
(missing or non-positive min_character_count) are logged and mapped to
null so the setup flow falls back to the generated-key path. Field names
match the ESS well-known schema (element-enterprise#261).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extract the show/hide password trailing-icon into a reusable
PasswordVisibilityToggle so every password field reveals plaintext the
same way and announces the same a11y labels. Reuse it from the login and
reset-identity password fields. Pure refactor, no behaviour change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
We were creating the same message twice by mistake.
Also, check the retrieved message for passwords before formatting the log line instead of after: this way we don't create a new formatted log line to just discard it