Revert "fix(trezor-client): send empty passphrase for standard wallets"
What changed, and why it matters
This commit undoes a previous change in the Trezor client Rust library. The original change made the software send an empty passphrase when using standard (non-hidden) wallets. The revert restores older behavior where, if the device is not asking for the passphrase on-device, the client acknowledges the passphrase request without providing an empty string. The practical effect depends on how the Trezor device firmware interprets the two acknowledgment types: one with an explicit empty passphrase and one without a passphrase field. It could affect which wallet derivation path or seed is used, potentially causing users to see a different wallet than expected, but the commit itself does not clearly introduce theft or remote exploitation.
Treat this as a behavior change requiring review. Verify whether the reverted behavior is compatible with current Trezor firmware and whether it restores or removes a known bug. If the prior fix was security-relevant (e.g., to prevent derivation of an unintended wallet), this revert should be reviewed by the security team and accompanied by tests or documentation. End users should ensure their firmware and client versions are compatible and that standard wallets still derive the expected addresses after this change.
Security signals we found
Reverts a prior 'fix' related to passphrase handling for standard wallets
Changes the message sent to the hardware device during passphrase entry flow
Passphrase handling is a sensitive seed-derivation step
No explicit security explanation or advisory language in commit message
Evidence from the diff
The diff reverts a prior fix in rust/trezor-client/src/client/common.rs. Previously, on PassphraseRequest, the code checked req.on_device(): if true it called req.ack(true), otherwise it called req.ack_passphrase(String::new()). The reverted code now stores on_device and calls req.ack(!on_device). The two ack methods likely correspond to different Protobuf messages: ack_passphrase sends a PassphraseAck with an empty passphrase string, while ack sends a bare ButtonAck/PassphraseAck without the passphrase field. The change may alter how the device resolves a missing passphrase for standard wallets, which historically could lead to a different (legacy empty-passphrase) wallet being derived than when an explicit empty string is sent. This is a protocol-level behavior change, not a memory-safety bug or remote code execution vector.
Changed components
rust/trezor-client/src/client/common.rsPassphraseRequest handling in Trezor client libraryInspect captured patch +3 / −4
diff --git a/rust/trezor-client/src/client/common.rs b/rust/trezor-client/src/client/common.rs
index 0fbb6740..897f8497 100644
--- a/rust/trezor-client/src/client/common.rs
+++ b/rust/trezor-client/src/client/common.rs
@@ -221,10 +221,9 @@ pub fn handle_interaction<T, R: TrezorMessage>(resp: TrezorResponse<'_, T, R>) -
TrezorResponse::Failure(_) => resp.ok(), // assering ok() returns the failure error
TrezorResponse::ButtonRequest(req) => handle_interaction(req.ack()?),
TrezorResponse::PinMatrixRequest(_) => Err(Error::UnsupportedNetwork),
- TrezorResponse::PassphraseRequest(req) => handle_interaction(if req.on_device() {
- req.ack(true)?
- } else {
- req.ack_passphrase(String::new())?
+ TrezorResponse::PassphraseRequest(req) => handle_interaction({
+ let on_device = req.on_device();
+ req.ack(!on_device)?
}),
}
}
Why this scored 29/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.