fix(binarycodec): guard NO_ACCOUNT issuer collision in Issue parser#312
fix(binarycodec): guard NO_ACCOUNT issuer collision in Issue parser#312e-desouza wants to merge 2 commits into
Conversation
Adds an explicit error in from_parser when an IOU's issuer bytes equal the NO_ACCOUNT sentinel (rrrrrrrrrrrrrrrrrrrrBZbvji) and the currency field starts with 0x00 (standard IOU layout). Without this guard the parser would silently misclassify the IOU as an MPT issue and read four extra bytes, corrupting the field. The fix returns a descriptive error for that ambiguous combination rather than producing a silent misparse. Also clarifies in code comments that the MPT Issue wire format stores the sequence field in little-endian byte order (confirmed by the codec-fixture test suite), and adds two new tests: one verifying the sequence round-trip and one confirming the colliding-issuer path returns the expected error. Closes #256
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #312 +/- ##
=======================================
Coverage ? 84.24%
=======================================
Files ? 200
Lines ? 20752
Branches ? 0
=======================================
Hits ? 17483
Misses ? 3269
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
…sue::from_parser The byte[0] == 0x00 guard introduced to detect IOU/MPT ambiguity was wrong: MPT issuer account hashes can legitimately start with 0x00 (~1/256), which would reject valid MPT issues. The XRPL ledger prevents the address rrrrrrrrrrrrrrrrrrrrBZbvji from being assigned to any account, so NO_ACCOUNT is unambiguously an MPT type tag. Revert to treating NO_ACCOUNT as MPT unconditionally.
|
Follow-up to second opinion review: the |
Summary
Issue::from_parserwhen an IOU's issuer bytes equal theNO_ACCOUNTsentinel (rrrrrrrrrrrrrrrrrrrrBZbvji) and the currency field starts with0x00(standard IOU currency layout). Without this guard, the parser silently misclassifies such an IOU as an MPT issue and consumes four extra bytes from the parser stream, corrupting everything that follows (IssueNO_ACCOUNTsentinel collides with legitimate AccountID #256).test_issue_mpt_sequence_roundtrip_endian(JSON -> binary -> JSON survives for a known MPT issuance ID, verifying the LE storage) andtest_issue_from_parser_no_account_issuer_collision_returns_error(USD + NO_ACCOUNT issuer returns an explicit error instead of silently misparsing).What changed
src/core/binarycodec/types/issue.rs: expandedNO_ACCOUNTconstant doc comment; added byte[0] guard infrom_parser; clarified LE comment inTryFrom<Value>andSerialize.src/core/binarycodec/test/tx_encode_decode_tests.rs: two new tests for the MPT sequence round-trip and the colliding-issuer error path.How to validate
cargo test --release cargo clippy --features std,tokio-rt,embassy-rt,actix-rt,futures-rt,smol-rt,core,wallet,models,utils,helpers,json-rpc,websocket,cli -- -D warningsBoth pass with zero failures and zero warnings.
Closes #255, closes #256