-
Notifications
You must be signed in to change notification settings - Fork 924
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
refactor(share/shrex-nd): blacklist peers that send invalid data #2231
refactor(share/shrex-nd): blacklist peers that send invalid data #2231
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2231 +/- ##
==========================================
+ Coverage 55.81% 55.92% +0.11%
==========================================
Files 216 216
Lines 14130 14141 +11
==========================================
+ Hits 7886 7909 +23
+ Misses 5454 5442 -12
Partials 790 790
|
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 is also very good because now, if we have malicious peer who sends us bad data, it won't short-circuit the request, it'll just blacklist and keep going until it gets good shares. However, there's an issue with the err
inside of GetSharesByNamespace
in shrex getter: it's only ever returned in the case of not being able to get a peer from peer manager, but not in the case of a context timeout. Why is this the case? Shouldn't we errors.Join the context err as well during timeout and return it? esp since we doing have any checks for ctx deadline exceeded in cascade getter
Also this would be a very good candidate for swamp test.
Nice find, we used to have all errors joined before relatively recent hotfix this one I'll open another PR to fix it, since it is unrelated to this change and there is also same problem in |
@walldiss needs rebase |
# Conflicts: # share/getters/shrex.go
Overview
Shrex should blacklist peers that send bad data.