qt: don't store python tuple in a qt QVariant.
What changed, and why it matters
This commit fixes a crash or misbehavior in Electrum's Qt address list. The developer suspects that storing a Python tuple inside a Qt data container (QVariant) was causing problems, so they converted the address index tuple into a plain sortable string before storing it. There is no direct evidence in the commit that this is a security vulnerability; it appears to be a stability/bug-fix change.
Treat as a regular bug-fix/stability patch. Reviewers may want to verify that address_index_as_sortable_key handles all expected AddressIndexGeneric types (str, tuple of ints) and that sorting behavior remains correct for all wallet address paths. No urgent security action is indicated by the available evidence.
Security signals we found
No explicit security framing by the vendor.
Change is defensive: avoids storing a Python tuple in a Qt QVariant, which could prevent type-conversion crashes or sorting failures.
No input validation, injection, or privilege changes visible in the diff.
No references to CVEs, advisories, or security researchers in the commit or supplied materials.
Evidence from the diff
The patch changes electrum/gui/qt/address_list.py. Previously the code stored the raw Python tuple returned by wallet.get_address_index(address) as Qt user data (QVariant) via setData() with role ROLE_SORT_ORDER. The commit adds a helper address_index_as_sortable_key() that converts the tuple into a zero-padded hexadecimal string, and stores that string instead. It also moves ROLE_ADDRESS_STR from column 0 to the TYPE column. The commit message frames this as an ‘educated guess’ to fix issue #10335, attributing the problem to Qt/PyQt type-wrapping pickiness.
Changed components
electrum/gui/qt/address_list.pyQt address list sorting functionalityInspect captured patch +6 / −2
diff --git a/electrum/gui/qt/address_list.py b/electrum/gui/qt/address_list.py
index b14abc1..80e5f09 100644
--- a/electrum/gui/qt/address_list.py
+++ b/electrum/gui/qt/address_list.py
@@ -44,6 +44,7 @@ from ..messages import MSG_FREEZE_ADDRESS
if TYPE_CHECKING:
from .main_window import ElectrumWindow
+ from electrum.wallet import AddressIndexGeneric
class AddressUsageStateFilter(IntEnum):
@@ -219,9 +220,9 @@ class AddressList(MyTreeView):
else:
address_item[self.Columns.TYPE].setText(_('receiving'))
address_item[self.Columns.TYPE].setBackground(ColorScheme.GREEN.as_color(True))
- address_item[0].setData(address, self.ROLE_ADDRESS_STR)
+ address_item[self.Columns.TYPE].setData(address, self.ROLE_ADDRESS_STR)
address_path = self.wallet.get_address_index(address)
- address_item[self.Columns.TYPE].setData(address_path, self.ROLE_SORT_ORDER)
+ address_item[self.Columns.TYPE].setData(self.address_index_as_sortable_key(address_path), self.ROLE_SORT_ORDER)
address_path_str = self.wallet.get_address_path_str(address)
if address_path_str is not None:
address_item[self.Columns.TYPE].setToolTip(address_path_str)
@@ -243,6 +244,9 @@ class AddressList(MyTreeView):
# update counter
self.num_addr_label.setText(_("{} addresses").format(num_shown))
+ def address_index_as_sortable_key(self, address_index: 'AddressIndexGeneric'):
+ return address_index if isinstance(address_index, str) else ''.join(f'{i:08x}' for i in address_index)
+
def refresh_row(self, key, row):
assert row is not None
address = key
Why this scored 21/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.