-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Re-)add handling for ChannelUpdate::message_flags
#3144
(Re-)add handling for ChannelUpdate::message_flags
#3144
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #3144 +/- ##
==========================================
+ Coverage 89.83% 90.23% +0.39%
==========================================
Files 121 121
Lines 98900 103329 +4429
Branches 98900 103329 +4429
==========================================
+ Hits 88847 93237 +4390
- Misses 7457 7462 +5
- Partials 2596 2630 +34 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, good catch! Not sure why I was under the impression the whole field has been deprecated back then.
LGTM
0fa0c2d
to
5b48f3f
Compare
Address @tnull's nit and squashed: $ git diff-tree -U1 0fa0c2dc 5b48f3ff
diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs
index 6701a1806..0cc8f1323 100644
--- a/lightning/src/ln/msgs.rs
+++ b/lightning/src/ln/msgs.rs
@@ -3505,3 +3505,3 @@ mod tests {
timestamp: 20190119,
- message_flags: 0,
+ message_flags: 1, // Only must_be_one
channel_flags: if direction { 1 } else { 0 } | if disable { 1 << 1 } else { 0 }, |
Fuzz is failing |
When the `htlc_maximum_msat` field was made mandatory in `ChannelUpdate` (in b0e8b73) we started ignoring the `message_flags` field entirely and always writing `1`. The comment updates indicated that the `message_flags` field was deprecated, but this is not true - only the `htlc_maximum_msat` indicator bit was deprecated, requiring it to be 1. If a node creates a `channel_update` with `message_flags` bits set other than the low bit, this will cause us to spuriously reject the message with an invalid signature error as we will check the message against the wrong hash. With today's current spec this is totally fine - the only other bit defined for `message_flags` is the `dont_forward` bit, which when set indicates we shouldn't accept the message into our gossip store anyway (though this may lead to spurious `warning` messages being sent to peers). However, in the future this may mean we start rejecting valid `channel_update`s if new bits are defiend.
Gossip messages should always use `test_msg_exact` to ensure they round-trip during signature validation.
5b48f3f
to
162b81f
Compare
Ugh, had to update the log regex: $ git diff-tree -U1 5b48f3ff 162b81fb
diff --git a/fuzz/src/full_stack.rs b/fuzz/src/full_stack.rs
index a2ae07a21..86f4ef4de 100644
--- a/fuzz/src/full_stack.rs
+++ b/fuzz/src/full_stack.rs
@@ -1781,3 +1781,3 @@ mod tests {
assert_eq!(log_entries.get(&("lightning::ln::peer_handler".to_string(), "Sending message to all peers except Some(PublicKey(0000000000000000000000000000000000000000000000000000000000000002ff00000000000000000000000000000000000000000000000000000000000002)) or the announced channel's counterparties: ChannelAnnouncement { node_signature_1: 3026020200b202200303030303030303030303030303030303030303030303030303030303030303, node_signature_2: 3026020200b202200202020202020202020202020202020202020202020202020202020202020202, bitcoin_signature_1: 3026020200b202200303030303030303030303030303030303030303030303030303030303030303, bitcoin_signature_2: 3026020200b202200202020202020202020202020202020202020202020202020202020202020202, contents: UnsignedChannelAnnouncement { features: [], chain_hash: 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000, short_channel_id: 42, node_id_1: NodeId(030303030303030303030303030303030303030303030303030303030303030303), node_id_2: NodeId(020202020202020202020202020202020202020202020202020202020202020202), bitcoin_key_1: NodeId(030303030303030303030303030303030303030303030303030303030303030303), bitcoin_key_2: NodeId(020202020202020202020202020202020202020202020202020202020202020202), excess_data: [] } }".to_string())), Some(&1));
- assert_eq!(log_entries.get(&("lightning::ln::peer_handler".to_string(), "Sending message to all peers except Some(PublicKey(0000000000000000000000000000000000000000000000000000000000000002ff00000000000000000000000000000000000000000000000000000000000002)): ChannelUpdate { signature: 3026020200a602200303030303030303030303030303030303030303030303030303030303030303, contents: UnsignedChannelUpdate { chain_hash: 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000, short_channel_id: 42, timestamp: 44, flags: 0, cltv_expiry_delta: 40, htlc_minimum_msat: 0, htlc_maximum_msat: 100000000, fee_base_msat: 0, fee_proportional_millionths: 0, excess_data: [] } }".to_string())), Some(&1));
+ assert_eq!(log_entries.get(&("lightning::ln::peer_handler".to_string(), "Sending message to all peers except Some(PublicKey(0000000000000000000000000000000000000000000000000000000000000002ff00000000000000000000000000000000000000000000000000000000000002)): ChannelUpdate { signature: 3026020200a602200303030303030303030303030303030303030303030303030303030303030303, contents: UnsignedChannelUpdate { chain_hash: 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000, short_channel_id: 42, timestamp: 44, message_flags: 1, channel_flags: 0, cltv_expiry_delta: 40, htlc_minimum_msat: 0, htlc_maximum_msat: 100000000, fee_base_msat: 0, fee_proportional_millionths: 0, excess_data: [] } }".to_string())), Some(&1));
assert_eq!(log_entries.get(&("lightning::ln::peer_handler".to_string(), "Sending message to all peers except Some(PublicKey(0000000000000000000000000000000000000000000000000000000000000002ff00000000000000000000000000000000000000000000000000000000000002)) or the announced node: NodeAnnouncement { signature: 302502012802200303030303030303030303030303030303030303030303030303030303030303, contents: UnsignedNodeAnnouncement { features: [], timestamp: 43, node_id: NodeId(030303030303030303030303030303030303030303030303030303030303030303), rgb: [0, 0, 0], alias: NodeAlias([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), addresses: [], excess_address_data: [], excess_data: [] } }".to_string())), Some(&1)); |
self.chain_hash.write(w)?; | ||
self.short_channel_id.write(w)?; | ||
self.timestamp.write(w)?; | ||
let all_flags = self.flags as u16 | ((MESSAGE_FLAGS as u16) << 8); | ||
all_flags.write(w)?; | ||
// Thw low bit of message_flags used to indicate the presence of `htlc_maximum_msat`, and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: s/Thw/The
FYI mutants is failing |
Yea, mutants is gonna be somewhat informational for now - tells us where our coverage is short but we don't really need to hold up a PR on it. |
When the
htlc_maximum_msat
field was made mandatory inChannelUpdate
(in b0e8b73) westarted ignoring the
message_flags
field entirely and alwayswriting
1
. The comment updates indicated that themessage_flags
field was deprecated, but this is not true - only the
htlc_maximum_msat
indicator bit was deprecated, requiring it tobe 1.
If a node creates a
channel_update
withmessage_flags
bits setother than the low bit, this will cause us to spuriously reject
the message with an invalid signature error as we will check the
message against the wrong hash.
With today's current spec this is totally fine - the only other bit
defined for
message_flags
is thedont_forward
bit, which whenset indicates we shouldn't accept the message into our gossip store
anyway (though this may lead to spurious
warning
messages beingsent to peers). However, in the future this may mean we start
rejecting valid
channel_update
s if new bits are defiend.