Summary

Fix incomplete zeroization of intermediate secret buffers in the midnight-node toolkit, ensuring wallet seeds and signing keys are erased from heap memory after use. This addresses audit finding A2 (Low severity) from the Least Authority Node DIFF Audit.

🎫 PM-22034 📐 Engineering

Motivation

The toolkit's signing key type zeroizes on drop, but secret values are converted into ordinary String and Vec<u8> buffers for CLI argument passing. These containers lack wipe-on-drop guarantees, leaving sensitive material in process memory until the OS reclaims the pages. An attacker with memory read access could recover these secrets long after they should have been erased.

This change explicitly zeroizes the intermediate buffers after they are no longer needed, closing the gap identified in the security audit.

Changes

Implementation:

• Add zeroize import and a zeroize_string helper to util/toolkit/src/toolkit_js/mod.rs
• Zeroize intermediate Vec<u8> serialization buffer in execute_deploy after hex encoding
• Zeroize hex-encoded signing key string in execute_deploy after execute_js returns
• Zeroize hex-encoded seed string in execute_maintain after execute_js returns
• Verify build (cargo check), tests (cargo test), and lint (cargo clippy) pass

🧪 QA Note — Zeroization Testing

Zeroization correctness (ensuring heap buffers are actually overwritten with zeros before drop) cannot be validated by standard Rust unit tests because the memory is freed immediately afterward and the borrow checker prevents inspecting it. The zeroize crate provides this guarantee via volatile writes and compiler fences, and its own upstream tests cover the correctness of the zeroization primitives.

For this PR, validation is limited to:

• Successful compilation (cargo check / cargo clippy)
• Existing tests continue to pass (cargo test)
• Code review confirming zeroize is called on the correct buffers at the correct points

If QA requires dedicated zeroization verification (e.g., Miri runs, custom allocator tests, or manual memory inspection), please flag this before merge and we can add the appropriate test infrastructure.

📌 Submission Checklist

• Changes are backward-compatible (or flagged if breaking)
• Pull request description explains why the change is needed
• Self-reviewed the diff
• I have included a change file, or skipped for this reason: [reason]
• If the changes introduce a new feature, I have bumped the node minor version
• Update documentation (if relevant)
• No new todos introduced

🔱 Fork Strategy

• Node Runtime Update
• Node Client Update
• Other
• N/A

🗹 TODO before merging

• Ready for review