-
Notifications
You must be signed in to change notification settings - Fork 32
GH-686 Don't allow extreme rate packs; reject Gossip about extreme rate packs #745
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
base: master
Are you sure you want to change the base?
Conversation
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.
This PR is being reviewed by Cursor Bugbot
Details
Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| let pieces = vec![ | ||
| &inner_string[0..index_of_space_after_pk], | ||
| addr_string.as_str(), | ||
| &inner_string[index_of_space_after_pk + 1..], |
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.
Bug: Slice bounds panic when no space found in string
The Display implementation for AccessibleGossipRecord searches for a space character starting at position 9 in inner_string. If no space is found before the end of the string, the while loop exits with index_of_space_after_pk equal to inner_string.len(). The subsequent slice &inner_string[index_of_space_after_pk + 1..] would then try to create a slice starting at len + 1, causing an index out-of-bounds panic. The code assumes a space always exists but doesn't verify one was actually found before using the index.
| candidate.hi.exit_service_rate, | ||
| "exit_service_rate", | ||
| ); | ||
| Ok(candidate) |
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.
Bug: Rate pack limits panics instead of returning errors
The rate_pack_limits() function returns Result<RatePackLimits, PersistentConfigError> but panics on syntax errors and invalid limit ordering instead of returning errors. This is inconsistent with similar functions like rate_pack(), payment_thresholds(), and scan_intervals() that use combined_params_get_method and properly return parsing errors via the Result type. The syntax error handling via unwrap_or_else(|| panic!(...)) and the validation in check_rate_pack_limit_order that panics on low >= high both violate the function's contract of returning errors.
Note
Enforces rate-pack limits in config and gossip, adds DB support and migration, introduces malefactor banning, and refactors neighborhood initialization with broad test updates.
CURRENT_SCHEMA_VERSIONto12; add migration11_to_12inserting defaultrate_pack_limits.rate_pack_limits; update initializer and tests accordingly.RatePackLimitsandDEFAULT_RATE_PACK_LIMITS; validateRatePackon configuration and during gossip processing.PersistentConfigurationto readrate_pack_limits; add factory and "invalid" placeholders.Malefactortype and switch ban path to carry structured data; handlers may return multiple results.Displayfor records,agrs_to_string).PersistentConfigurationFactoryand constructGossipAcceptorwith limits.rate-packvalues, longer timeouts, and additional nodes; add new unit tests for limits and parsing.timefeaturelocal-offset; minor renames/var tweaks; .gitignore adds Copilot files.Written by Cursor Bugbot for commit 45e87b6. This will update automatically on new commits. Configure here.