SFT-6356: adjusted input already signed message
What changed, and why it matters
This commit is a trivial user-facing string change inside an assertion. It merges two separate 'already signed' error messages into one and updates the text. There is no functional change to how the code behaves, no security fix, and no vulnerability introduced.
No action required; this is a non-security UI/message cleanup.
Security signals we found
No security-relevant logic change
Assertion condition is logically equivalent before and after
Only error message text was modified
Evidence from the diff
In sign_psbt_task.py, two consecutive assertions (assert not inp.added_sig and assert not inp.tap_key_sig) were replaced by a single equivalent assertion using or with a unified message string. The logical condition remains the same: the code still fails if either signature field is present. The change only affects the assertion message shown if the condition is violated.
Changed components
ports/stm32/boards/Passport/modules/tasks/sign_psbt_task.pyInspect captured patch +1 / −2
diff --git a/ports/stm32/boards/Passport/modules/tasks/sign_psbt_task.py b/ports/stm32/boards/Passport/modules/tasks/sign_psbt_task.py
index 31a0e72..1d4a7c8 100644
--- a/ports/stm32/boards/Passport/modules/tasks/sign_psbt_task.py
+++ b/ports/stm32/boards/Passport/modules/tasks/sign_psbt_task.py
@@ -80,8 +80,7 @@ async def sign_psbt_task(on_done, psbt):
# single pubkey <=> single key
which_key = inp.required_key
- assert not inp.added_sig, "already done??"
- assert not inp.tap_key_sig, "already done taproot??"
+ assert not (inp.added_sig or inp.tap_key_sig), "This transaction has already been signed"
if len(inp.subpaths) > 0 and \
(inp.subpaths[which_key][0] == psbt.my_xfp or
Why this scored 15/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.