Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Found by: Robby and michaelortmann
Patch by: michaelortmann
Fixes: #1604
One-line summary:
Fixes a channel member list corruption regression
Additional description (if needed):
got353()
check for capability userhost-in-names was wrong. It checked only, if this cap is available. But it must also check, if it is enabled.This bug affects eggdrop version 1.10.0rc1 and higher.
It is triggered, when the server supports CAP userhost-in-names and eggdrop doesnt request this CAP. In such case it would handle a 353 numeric from server as if userhost-in-names was negotiatad successfully and would then end up attempting to split the server message into
nick!host
. Without userhost-in-names CAP active, there is no!host
part. In then end this would lead to adding a new member with empty nick into the channel member list.Test cases demonstrating functionality (if applicable):
Tested with and without the following line in
eggdrop.conf
:set cap-request "userhost-in-names"
Test 1 - with cap request
Test 2 - with cap request