Add SeedQR support for BIP39 passphrase input

[blakemountain]

Description

Problem or Issue being addressed

SeedSigner's passphrase QR workflow accepts plaintext UTF-8 QR codes, but does not accept Standard SeedQR or Compact SeedQR as passphrase input.

This PR adds the option to use either SeedQR format as a BIP39 passphrase while preserving the existing plaintext QR behavior.

Solution

When scanning a passphrase QR, Standard SeedQR and Compact SeedQR payloads are detected and decoded using the existing SeedQR decoding logic.

Because SeedQR represents BIP39 word indexes rather than the original text formatting, decoded SeedQR passphrases are reconstructed canonically as lowercase BIP39 words separated by single ASCII spaces.

Plain UTF-8 passphrase QR input continues to preserve the exact text provided.

Malformed SeedQR input is rejected rather than being accepted as an empty or otherwise unintended passphrase. The passphrase scan workflow displays an "Invalid QR" warning when this occurs.

Tests cover:

• Standard SeedQR passphrase decoding
• Compact SeedQR passphrase decoding
• Equivalent Standard/Compact representations
• Preservation of existing plaintext passphrase behavior
• Malformed SeedQR rejection
• Invalid passphrase QR handling

Additional Information

Tested on a Raspberry Pi Zero W with physical SeedSigner hardware.

Using the same seed, I tested equivalent passphrases supplied as:

• plaintext QR
• Standard SeedQR
• Compact SeedQR

All three produced the same wallet fingerprint.

Malformed SeedQR input was also tested on the physical device and correctly displayed the invalid QR warning.

The branch was rebased onto the current 3rdIteration/dev before final testing.

Screenshots

No screenshots included. The only new screen behavior is the invalid QR warning using the existing warning UI.

---

This pull request is categorized as:

• New feature
• Bug fix
• Code refactor
• Documentation
• Other

---

Checklist

I ran pytest locally

• All tests passed before submitting the PR
• I couldn't run the tests
• N/A

Full suite result: 1026 passed, 58 skipped, 1 xfailed

---

I included screenshots of any new or modified screens

Should be part of the PR description above.

• Yes
• No
• N/A

---

I added or updated tests

Any new or altered functionality should be covered in a unit test. Any new or updated sequences require FlowTests.

• Yes
• No, I'm a fool
• N/A

---

I tested this PR hands-on on the following platform(s):

• Raspberry Pi OS Manual Build
• SeedSigner OS on a Pi0/Pi0w board
• Emulator

---

I have reviewed these notes:

• Keep your changes limited in scope.
• If you uncover other issues or improvements along the way, ideally submit those as a separate PR.
• The more complicated the PR, the harder it is to review, test, and merge.
• We appreciate your efforts, but we're a small team of volunteers so PR review can be a very slow process.
• Please only "@" mention a contributor if their input is truly needed to enable further progress.

• I understand

---

Thank you! Please join our Devs' Telegram group to get more involved.

[hannpet]

Quick question... Does this also accept encrypted-seedqr?
That would be awesome and exactly what I was looking for...!

[blakemountain]

Quick question... Does this also accept encrypted-seedqr? That would be awesome and exactly what I was looking for...!

Not currently. This PR only adds passphrase input support for Standard SeedQR and Compact SeedQR. Encrypted SeedQR support would require additional decryption handling and isn't included in the current implementation.

[hannpet]

Hmm... but as I see it, scanning and decoding a encrypted seedqr already exists as a feature in shieldsigner... So wouldn't this be super trivial to use in your pr aswell? To me that honestly feels more like a little oversight.. because why should it happily accept encrypted seed-qr's in one part of the app, but then play dumb a few menu items down the road? 😉 I think that confuses the user. If encrypted seed-qr's are a thing in shieldsigner, every function that scans seed-qr's should be expected to be able to handle each flavor like the rest of the system.
That's no criticism of your work btw, I very much appreciate this pr and I cheer it gets merged soon..!

[blakemountain]

Hmm... but as I see it, scanning and decoding a encrypted seedqr already exists as a feature in shieldsigner... So wouldn't this be super trivial to use in your pr aswell? To me that honestly feels more like a little oversight.. because why should it happily accept encrypted seed-qr's in one part of the app, but then play dumb a few menu items down the road? 😉 I think that confuses the user. If encrypted seed-qr's are a thing in shieldsigner, every function that scans seed-qr's should be expected to be able to handle each flavor like the rest of the system. That's no criticism of your work btw, I very much appreciate this pr and I cheer it gets merged soon..!

i understand and largely agree with your points/logic. my stance is to present a clean simple pull request so the maintainers can quickly understand it, and then ultimately decide if its something they want to implement in their maintained project. if it gets through, id happily put together another pr for your request, but for now im patiently waiting to see if my first portion gets approved. thanks for your input. if this goes stale, feel free to fork my work and add the features you want, thats the beauty of open source!

[hannpet]

Yes, sounds reasonable!
Still I think there's probably a higher chance it gets merged if you add those three lines now, so the feature behaves as expected, no matter what seed-qr gets thrown at it.
But yes I'll have to make a custom build if the decision makers 😉 don't find merit in painlessly storing long passphrases on steel and (ideally a bit protected) on paper. This route is for people who (like me) feel uncomfortable putting too much trust in the diy-javacards blackbox and are looking for a second way of doing things.