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

Make fuzz targets deterministic

Public commit record

What the developer wrote

Authored by Joost Jager

80/100 · Strong
Make fuzz targets deterministic

Gate all SystemTime::now() and Instant::now() calls in production code
with #[cfg(all(feature = "std", not(fuzzing)))] so that fuzz targets
produce consistent results regardless of wall-clock time. For each
location, the existing no-std fallback (highest_seen_timestamp, None,
or a constant) is reused under fuzzing.

Also force deterministic hashing when the fuzzing cfg is active,
rather than requiring the LDK_TEST_DETERMINISTIC_HASHES env var.

AI tools were used in preparing this commit.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit changes how the Lightning Dev Kit code behaves when running under fuzz testing. Normally, the code uses the real wall-clock time and random hashing. Under fuzzing, it now uses fixed fallback values and deterministic hashing so that fuzz tests produce the same results every run. This is a testing-harness improvement, not a fix for an exploitable security bug in production. It does not change behavior for normal users.

Recommended action

No immediate action required. Reviewers may verify that the fuzzing cfg is not accidentally enabled in release builds and that fallback time values remain safe for fuzz coverage. Consider whether any newly introduced #[cfg(all(feature = "std", fuzzing))] branches need additional test coverage.

Security signals we found

01

Conditional compilation change (cfg gating) for time sources under fuzzing

02

Deterministic hashing automatically enabled under fuzzing cfg

03

Reuses existing no-std fallback paths for time values

04

No production code behavior change outside fuzzing builds

Risk score

Why this scored 19/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 2/15
Confidence 9/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.