Skip to content

Token definition generator silently emits an empty table #446

Description

@BitHighlander

Triaged during the 7.14.2 residual pass and deferred out of 7.14.2 as low. Still present at release/7.14.2 head.

Evidence

lib/firmware/CMakeLists.txt:62-65 (bare add_custom_target, no output verification) + deps/python-keepkey/keepkeylib/eth/ethereum_tokens.py:26-33 at the current pin 81e581fa94d39868b63b4b7afbf712dca0c9091a

Assessment

Still present, unchanged in substance. The python-keepkey pin moved from fabd6c61 to 81e581fa over the 45 commits, but the checked-out ethereum_tokens.py at the new pin has the identical failure mode: add_tokens() does if not os.path.exists(dirname): return when keepkeylib/eth/ethereum-lists is unpopulated, and if not os.path.isfile(fullpath): return inside the loop — a return, not a continue, so one non-file entry truncates that whole network's list. deps/python-keepkey/.gitmodules at head still declares keepkeylib/eth/ethereum-lists as a nested submodule, so it is empty in any non-recursive checkout. lib/firmware/CMakeLists.txt still invokes both generators as bare COMMANDs with no check on the emitted .def, so a zero-length table builds green.

Not host-reachable: there is no protobuf field anywhere on this path — it is a build-time defect only, so it sits outside the stated threat model entirely. The on-device consequence of an empty table is also fail-safe rather than deceptive at this head: a contract absent from the table yields the UnknownToken sentinel, ethereumFormatAmount() prints "Unknown token value" (lib/firmware/ethereum.c:347-349), and commit 9707970 routes exactly that case into the raw-calldata disclosure plus the AdvancedMode block (ethereum.c:781-798). So a truncated table degrades the UX, it does not produce a wrong-symbol confirmation screen.

What survives is a reproducibility/provenance defect, and it got slightly more pointed on this branch: c89c7d0 pins the builder image by digest and records it in provenance, i.e. the release now makes a reproducible-build claim that a third party cannot actually check for the token table, because a clean non-recursive tree silently produces a different (empty or partial) table with no build failure. CI itself uses submodules: recursive at .github/workflows/release.yml:35/55/139, so the shipped 7.14.2 image is fine. Low, and proportionate to defer: file an issue to make the generator exit non-zero on a missing/empty ethereum-lists and to have CMake assert the .def is non-empty, before the next release that leans harder on the provenance claim.


Deferred because 7.14.2 is a minimal security release; this did not clear the bar for a late change. Filed so it is not lost.

Metadata

Metadata

Assignees

No one assigned

    Labels

    evmEthereum / EVM signingsecuritySecurity-relevant defect or hardening

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions