-
-
Notifications
You must be signed in to change notification settings - Fork 679
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #3243 +/- ##
==========================================
- Coverage 65.14% 65.13% -0.02%
==========================================
Files 507 507
Lines 57173 57199 +26
==========================================
+ Hits 37246 37254 +8
- Misses 16027 16045 +18
Partials 3900 3900
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ 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.
I have concerns here that because we do not recalculate rejected-ness, we may cascade fail later events incorrectly.
A reminder of what sets rejected = true:
- Passes authorization rules based on the event’s auth events, otherwise it is rejected.
- Passes authorization rules based on the state before the event, otherwise it is rejected.
Rejected-ness is not a pure yes/no (unlike say hash checks) because the server may fail to fetch the auth events / state before the event due to connectivity issues. At that point, the event is neither accepted nor rejected, it's indetermined.
It's unclear what the best course of action is when there are network connectivity issues as this can become an attack vector. It's clearly not correct to accept it (else an adversary in control of the network can just firewall off the server and send rubbish to it, and have the server merrily accept it). The opposite is a denial of service attack though: valid events can be made invalid by preventing the server talking to other servers. This isn't the only place where this can happen in federation today (/gme dishing up prev_events is another) so it's less bad I guess, but we definitely do need to keep retrying to fetch the events if we cannot.
Companion PR to matrix-org/gomatrixserverlib#421