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

refactor(zcash): route batch FFI through per-message checked preflight

Public commit record

What the developer wrote

Authored by Adam Tucker

62/100 · Adequate
refactor(zcash): route batch FFI through per-message checked preflight
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit rewrites how the Keystone hardware wallet handles Zcash batch transactions. Instead of checking each transaction message separately at every step, it now runs a single 'preflight' check that normalizes the messages, stores the checked result in a new container, and then requires that exact checked container for parsing and signing. The goal is to make sure the device signs only what it already inspected, reducing the chance that a malicious or malformed transaction slips through. The change is gated behind the 'cypherpunk' feature and only affects Zcash batch signing.

Recommended action

Treat this as a security-sensitive refactor: review the implementation of ZcashCheckedPczt for memory safety and tamper resistance, verify that the checked container cannot be modified between preflight and sign/parse, confirm app_zcash::preflight_batch_pczt_cypherpunk covers all checks previously performed by check_zcash_batch_message_cypherpunk plus ensure_pczt_has_signable_shielded_action, and run targeted tests/fuzzing on the new batch envelope serialization round-trip. If this commit fixes a known issue, request the vendor or reporter to disclose the CVE and advisory.

Security signals we found

01

Refactor moves security-critical checks from three separate call sites into a single preflight step

02

New checked container (ZcashCheckedPczt) binds parsed/signed data to the preflight output

03

Per-message normalization and digest stamping before signing

04

Removal of duplicate per-message checks in parse and sign paths

05

Potential new null-deref/invalid-pointer paths introduced by out-parameter checked_batch and is_null checks

06

UFVK no longer validated at signing time; trust shifted entirely to preflight output

07

No explicit memory-safety audit of ZcashCheckedPczt lifecycle visible in this diff

Risk score

Why this scored 32/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 5/15
Confidence 5/10
Evidence quality 3/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.