psbt: always confirm green outputs when recovery signing
What changed, and why it matters
This commit changes the logic in Blockstream Jade's PSBT signing flow so that, when the hardware wallet is acting as a 'recovery' key for a Green 2-of-3 wallet, it always asks the user to confirm outputs that belong to Green, rather than silently trusting them. Previously, the code skipped confirmation if Jade detected it was the recovery key and the output matched a Green script. The change flips the condition: now, if Jade is the recovery key OR the script does not match Green's expected pattern, the output must be confirmed. This is a defensive fix to prevent a compromised companion app or host from sneaking an unverified output past the user during recovery signing.
Treat as a security-hardening fix and include in the next firmware release. Review related recovery-signing paths for any other assumptions that backend-derived paths can be trusted without user confirmation. Consider adding regression tests that simulate recovery-key signing with both matching and non-matching Green outputs to ensure confirmation is always required.
Security signals we found
Logic inversion in authorization/confirmation path
Recovery-key signing path previously trusted Green-classified outputs without user confirmation
Comment explicitly frames change around inability to verify output ownership in recovery path
Small, surgical patch in hardware-wallet signing code
No explicit CVE, advisory, or researcher attribution in commit
Evidence from the diff
In main/process/sign_psbt.c, the function psbt_update_outputs() decides whether to confirm transaction outputs with the user. The original condition skipped confirmation when iter.is_ga_2of3_recovery_key was true AND verify_ga_script_matches() returned true. The patch inverts the first term: confirmation is now required when iter.is_ga_2of3_recovery_key is true OR verify_ga_script_matches() fails. The inline comment is updated to reflect that, when Jade matches the recovery key, the backend path is derived from the user key, so the device cannot independently verify that the output belongs to the Green 2of3 setup and must therefore prompt the user. This is a partial, targeted change (two lines) with no broader refactoring.
Changed components
main/process/sign_psbt.cPSBT signing flowGreen 2of3 recovery signing pathOutput confirmation / user-prompt logicInspect captured patch +2 / −2
diff --git a/main/process/sign_psbt.c b/main/process/sign_psbt.c
index 0c0ad88..56451f8 100644
--- a/main/process/sign_psbt.c
+++ b/main/process/sign_psbt.c
@@ -623,8 +623,8 @@ static bool psbt_update_outputs(const network_t network_id, struct wally_psbt* p
continue;
}
- if (!iter.is_ga_2of3_recovery_key
- && !verify_ga_script_matches(
+ if (iter.is_ga_2of3_recovery_key
+ || !verify_ga_script_matches(
network_id, &iter.hdkey, recovery_p, path, path_len, tx_script, tx_script_len)) {
// Not able to verify that output belongs to green 2of3 when Jade matches recovery key
// as backend path is calculated from user key.
Why this scored 57/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.