Skip to content

feat: upgrade to xrpld 3.2.0 - #45

Open
shichengripple001 wants to merge 4 commits into
mainfrom
feat/xrpld-3.2.0
Open

feat: upgrade to xrpld 3.2.0#45
shichengripple001 wants to merge 4 commits into
mainfrom
feat/xrpld-3.2.0

Conversation

@shichengripple001

Copy link
Copy Markdown
Contributor

Summary

Re-opening PR #43 (which shows "Merged" from an earlier merge-then-revert cycle — that revert was to back out an unintended direct merge, not a rejection of the work; see #43 for full history).

  • Upgrade default rippled image from xrpllabsofficial/xrpld:3.2.0 to rippleci/xrpld:3.2.0 (org the team controls directly)
  • Fix binary-path/confArg and consensus-mode entrypoint handling for non-xrpllabsofficial images
  • Address preliminary security review findings F1-F7 from Preliminary Security Review — 2026-07-16 #44 (dependency CVE overrides, pinned GitHub Actions, workflow permissions, shell-injection fixes, ad-hoc install cleanup) — see the response comment on Preliminary Security Review — 2026-07-16 #44 for details
  • Drop Node.js 20 support (reached EOL 2026-04-30; also bundles an older undici implicated in real-network e2e flakiness)
  • Add mainnet-use disclaimer to README per Ajit's release sign-off feedback

Test plan

  • Full e2e suite passes on node-22/24 across standalone/local-network/snapshot/testnet modes
  • Typecheck and build pass
  • Verified live: fresh consensus-mode boot on new default image, stop/restart resume-from-volume, standalone mode

🤖 Generated with Claude Code

shichengripple001 and others added 4 commits July 23, 2026 15:13
gh release create reproduces the exact same behavior (title, generated
notes, prerelease/latest flags) using a tool already present on every
GitHub-hosted runner, removing one more third-party action from the
release pipeline's trust boundary.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Per Ajit's release sign-off feedback in #xrpl-devnets: this is a
developer tool for local/Devnet/Testnet use, not a mainnet-safe wallet —
it doesn't provide the private-key security practices real fund custody
requires.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…lumes

Records which image last started the persistent --local-network volumes
(~/.xrpl-up/local-network-image.txt) and blocks start with a clear error
if a different image is used against a volume that still has data —
matching real precedent from the 3.1.x -> 3.2.0 upgrade, which moved the
DB/log paths and silently broke existing volumes.

Only triggers when there's actual data at risk (fresh volumes have
nothing to conflict with) and only against a previously recorded image
(older xrpl-up versions never wrote this file, so upgrading xrpl-up
itself doesn't spuriously block). `xrpl-up reset` clears the record
since it also wipes the volumes.

Verified live: mismatched image blocks with a clear message pointing to
`xrpl-up reset`; reset clears the record; same-image restart and
fresh-after-reset starts both work without a false positive.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Genericize the comment and the user-facing error message — the guard
handles any image mismatch, not just that one past incident.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant