Skip to content

Secret key material has no in-memory zeroization strategy after signing #37

Description

@ndii-dev

sendPayment() in src/services/stellar.ts (once wired to getSecretKey()) will hold the raw secret as a JS string through Keypair.fromSecret and signing. JS strings are immutable and often interned/retained by the engine's GC well past their last explicit reference, so "just let it go out of scope" is not a real mitigation — this needs an actual design decision (e.g. using a mutable byte buffer that can be explicitly overwritten, understanding Hermes's actual memory behavior) rather than assuming garbage collection equals erasure.

Definition of done:

  • Written analysis of what Hermes actually does with short-lived string data (does anything currently give a real guarantee, or is this fundamentally unsolvable at the JS layer and needs to move to native code?)
  • Best-achievable mitigation implemented and documented with its actual limitations stated plainly, not oversold
  • No secret-shaped string literals left in any exception/error object that might be caught and logged elsewhere

Before opening a PR for this issue, read CONTRIBUTING.md.

This is not a starter-issue. The Definition of done above is the full
acceptance criteria, not a subset to sample from — a PR that addresses part
of it is an unfinished issue, not a smaller one. Your PR must include, in
the PR description itself:

  • Root cause / design-decision rationale in your own words — not a restatement of this issue
  • Every Definition of done bullet above addressed explicitly, with a one-line note on how
  • Evidence the code actually runs: pasted test/build output, a screen recording or before/after screenshots for UI changes, or real (non-mocked) logs for network/contract-facing work
  • New or updated tests included and shown passing (paste the output)
  • Any adjacent/related behavior this issue calls out re-verified, not assumed unaffected

PRs missing these will be sent back before review, not reviewed and rejected — please do this up front.

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardOfficial Campaign | FWC26Campaign: Official Campaign | FWC26

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions