Fix typo in `_encode_tlv` leading to confused encoding
What the developer wrote
Authored by Matt Corallo
Fix typo in `_encode_tlv` leading to confused encoding
What changed, and why it matters
This commit fixes a small but meaningful typo in a Rust macro used to encode Lightning protocol data. The misplaced parenthesis could cause the macro to match the wrong pattern when encoding optional fields that use a custom encoding. That could lead to messages being serialized incorrectly, which in a Lightning node might cause peers to reject messages, fail to parse state, or potentially behave in unexpected ways during channel operations. The fix is one character moving a closing parenthesis.
Review all call sites of `_encode_tlv!` that use the `(option, encoding: (Type, encoder))` form to confirm the corrected macro now matches as intended, and run the project's serialization round-trip tests. Consider adding a regression test that exercises this specific macro arm with the optional `$self` parameter. No immediate emergency response is indicated, but the fix should be included in the next release because malformed encoding can cause interoperability or state-recovery issues.
Security signals we found
Serialization format confusion in protocol message encoding macro
Potential silent mismatch in TLV optional-field encoding arm
Single-character fix in a widely-used serialization macro
Could affect Lightning wire messages and persisted state serialization
Evidence from the diff
In lightning/src/util/ser_macros.rs, the _encode_tlv! macro arm for (option, encoding: ($fieldty: ty, $encoding: ident)) had its closing parenthesis placed before the optional $(, $self: ident)? fragment instead of after it. This changes the macro’s pattern matching: with the parenthesis in the wrong place, the optional $self is treated as part of the outer macro invocation rather than part of the (option, encoding: ...) type tuple. The fix moves ) to correctly close the encoding tuple. Because this is a macro used pervasively for TLV serialization of optional fields, incorrect matches could silently encode the wrong data or fall through to a different arm, producing invalid or ambiguous wire formats.
Changed components
lightning/src/util/ser_macros.rs_encode_tlv! macroTLV/optional field serialization paths using custom encodingsInspect captured patch +1 / −1
diff --git a/lightning/src/util/ser_macros.rs b/lightning/src/util/ser_macros.rs
index c023ab4..53777d2 100644
--- a/lightning/src/util/ser_macros.rs
+++ b/lightning/src/util/ser_macros.rs
@@ -80,7 +80,7 @@ macro_rules! _encode_tlv {
($stream: expr, $type: expr, $field: expr, upgradable_option $(, $self: ident)?) => {
$crate::_encode_tlv!($stream, $type, $field, option);
};
- ($stream: expr, $type: expr, $field: expr, (option, encoding: ($fieldty: ty, $encoding: ident) $(, $self: ident)?)) => {
+ ($stream: expr, $type: expr, $field: expr, (option, encoding: ($fieldty: ty, $encoding: ident)) $(, $self: ident)?) => {
$crate::_encode_tlv!($stream, $type, $field.as_ref().map(|f| $encoding(f)), option);
};
($stream: expr, $type: expr, $field: expr, (option, encoding: $fieldty: ty) $(, $self: ident)?) => {
Why this scored 61/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.