AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 36 Bitcoin

feat(solana): add off-chain message signing

Public commit record

What the developer wrote

Authored by Jakub Janků

88/100 · Strong
feat(solana): add off-chain message signing

Implements the Solana off-chain message signing standard v0
as specified here:

https://docs.anza.xyz/proposals/off-chain-message-signing

The implementation deviates from the spec in the supported
message formats --- the spec says that HW wallets should clear-
sign format 0 (ascii), blind-sign format 1 (short utf-8), and
not support format 2 (long utf-8) messages. We try to clear-sign
messages irrespective of the format. The rationale is that we
__can__ display even longer messages incl. some non-ascii chars
and thus the limitation is arbitrary. Moreover, this restriction
is removed in the newer v1 spec, see:

https://github.com/solana-foundation/SRFCs/discussions/3

Closes: https://github.com/trezor/trezor-firmware/issues/6759
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds a new Trezor feature: signing and verifying Solana off-chain messages. It is a feature implementation, not a fix for a known vulnerability. The code introduces new message types, parsing logic, user confirmation screens, and client helpers. There is no direct evidence in the commit of a security bug, but any new signing path increases the attack surface and must be reviewed carefully for parsing mistakes or user-interface spoofing.

Recommended action

Treat this as a security-sensitive feature addition. Conduct a focused review of the OCMS parser for length/offset/underflow bugs, confirm that user prompts are unspoofable and clearly distinguish sign vs. verify, verify that the derived key must match one of the declared signers, and ensure the Ed25519 signing is performed over the exact raw bytes the user confirmed. Fuzz the parser and run static analysis on the new modules before release.

Security signals we found

01

New signing code path added for Solana off-chain messages

02

Parsing of attacker-controlled binary message/envelope format introduced

03

User confirmation flow added for off-chain message signing and verification

04

Deviation from Solana OCMS v0 spec: all formats are clear-signed instead of blind-signed

05

No vendor disclosure of a security issue in commit message or changelog

Risk score

Why this scored 36/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 4/15
Affected reach 7/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.