| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \ \ \ \ \ \
| | |_|/ / / / /
| |/| | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Add third party rules hook for 3PID invites
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| |\| | | | | | |
| | | | | | | | |
| | | | | | | | | |
Add third party rules hook into create room
|
| | |/ / / / / / |
|
|\| | | | | | | |
|
| |/ / / / / / |
|
|\| | | | | | |
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Handle HttpResponseException when using federation client.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Otherwise we just log exceptions everywhere.
|
|\| | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Fix email notifications for unnamed rooms with multiple people
|
| | | | | | | | | |
|
| | |/ / / / / /
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
When we try and calculate a description for a room for with no name but
multiple other users we threw an exception (due to trying to subscript
result of `dict.values()`).
|
|\| | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Only start background group attestation renewals on master
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
Fix 3PID invite room state over federation.
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
Allow server admins to define implementations of extra rules for allowing or denying incoming events
|
|\| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
Prometheus histograms are cumalative
|
| | | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Fix background job for deactivated flag
|
| | | | | | | | | | | | | |
|
| |\| | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
matrix-org/babolivier/account_validity_deactivated_accounts_2
Don't send renewal emails to deactivated users (second attempt)
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Purge jobs don't delete the latest event in a room in order to keep the forward extremity and not break the room. On the other hand, get_state_events, when given an at_token argument calls filter_events_for_client to know if the user can see the event that matches that (sync) token. That function uses the retention policies of the events it's given to filter out those that are too old from a client's view.
Some clients, such as Riot, when loading a room, request the list of members for the latest sync token it knows about, and get confused to the point of refusing to send any message if the server tells it that it can't get that information. This can happen very easily with the message retention feature turned on and a room with low activity so that the last event sent becomes too old according to the room's retention policy.
An easy and clean fix for that issue is to discard the room's retention policies when retrieving state.
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
information (#12)
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
As per MSC1763, 'Retention is only considered for non-state events.', so don't filter out state events based on the room's retention policy.
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
The `http_proxy` and `HTTPS_PROXY` env vars can be set to a `host[:port]` value which should point to a proxy.
The address of the proxy should be excluded from IP blacklists such as the `url_preview_ip_range_blacklist`.
The proxy will then be used for
* push
* url previews
* phone-home stats
* recaptcha validation
* CAS auth validation
It will *not* be used for:
* Application Services
* Identity servers
* Outbound federation
* In worker configurations, connections from workers to masters
Fixes #4198.
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
While this is not documented in the spec (but should be), Riot (and other clients) revoke 3PID invites by sending a m.room.third_party_invite event with an empty ({}) content to the room's state.
When the invited 3PID gets associated with a MXID, the identity server (which doesn't know about revocations) sends down to the MXID's homeserver all of the undelivered invites it has for this 3PID. The homeserver then tries to talk to the inviting homeserver in order to exchange these invite for m.room.member events.
When one of the invite is revoked, the inviting homeserver responds with a 500 error because it tries to extract a 'display_name' property from the content, which is empty. This might cause the invited server to consider that the server is down and not try to exchange other, valid invites (or at least delay it).
This fix handles the case of revoked invites by avoiding trying to fetch a 'display_name' from the original invite's content, and letting the m.room.member event fail the auth rules (because, since the original invite's content is empty, it doesn't have public keys), which results in sending a 403 with the correct error message to the invited server.
|
| |\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Reject pending invites on deactivation
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
|
| | | | | | | | | | | | | | | |
|
| |/ / / / / / / / / / / / /
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
rooms
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Python 2's filter() function and Python 3's don't return the same type when processing a string (respectively str and filter), therefore use six's compatibility mapping (which resolves to itertools.ifilter() if using Python2), then generate a string from the filtered list, in order to ensure consistent behaviour between Python 2 and Python 3.
|
| |\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Don't treat 3PID revocation as a new 3PID invite
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
matrix-org/babolivier/account_validity_template_encode"
This reverts commit 84e695f506faf54982b9e19dceb9c02acffad95f, reversing
changes made to 99eec6d2d5cc76e645c3fd7ca6cda85b2bab6feb.
|
| | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
This reverts commit 665dd9f7f8db2f8d38f454d4d5b96efcf163a5db.
|
| | |/ / / / / / / / / / / / /
| |/| | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Regardless of the Python version
|
| | | | | | | | | | | | | | | |
|
| |/ / / / / / / / / / / / / |
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ \
| | |_|/ / / / / / / / / / /
| |/| | | | | | | | | | | | |
|
| | |_|/ / / / / / / / / /
| |/| | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ \ \
| | |_|/ / / / / / / / / /
| |/| | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \ \
| | |/ / / / / / / / / / /
| |/| | | | | | | | | | | |
Don't log exception when failing to fetch remote content.
|
| | | |_|_|/ / / / / / /
| | |/| | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
In particular, let's not log stack traces when we stop processing
becuase the response body was too large.
|
|\| | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
|\| | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
|\| | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
This code confused the hell out of me today. Split _get_new_device_messages
into its two (unrelated) parts.
|
|\| | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
|\| | | | | | | | | | |
| |_|/ / / / / / / / /
|/| | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
* remove 2.7 from CI and publishing
* fill out classifiers and also make it not be installed on 3.5
* some minor bumps so that the old deps work on python 3.5
|
| |\ \ \ \ \ \ \ \ \ \
| | | |_|_|_|_|/ / / /
| | |/| | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \
| | | |_|_|_|_|_|_|_|/
| | |/| | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Moves the warning about password resets being disabled to the point where a user actually tries to reset their password. Is this an appropriate place for it to happen?
Also removed the disabling of msisdn password resets when you don't have an email config, as that just doesn't make sense.
Also change the error a user receives upon disabled passwords to specify that only email-based password reset is disabled.
|
| | |_|_|_|_|_|_|_|/
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
* add monthly active users to phonehome stats
|
| |\ \ \ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
Fix key verification when key stored with null valid_until_ms
|
| |\ \ \ \ \ \ \ \ \ \ \
| | |_|_|_|_|/ / / / / /
| |/| | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
matrix-org/babolivier/account_validity_send_mail_auth
Don't check whether the user's account is expired on /send_mail requests
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Account validity: allow defining HTML templates to serve the user on account renewal attempt
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Add ability to pass arguments to looping calls
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \ \ \ \
| | |_|/ / / / / / / / / / / /
| |/| | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
matrix-org/babolivier/access-rules-public-restricted
Force the access rule to be "restricted" if the join rule is "public"
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
| | |/ / / / / / / / / / / / |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
some reason (need to investigate)
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| |/ / / / / / / / / / / / |
|
|/ / / / / / / / / / / / |
|
|\ \ \ \ \ \ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Port #5644 to dinsic
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
When a user creates an account and the 'require_auth_for_profile_requests' config flag is set, and a client that performed the registration wants to lookup the newly-created profile, the request will be denied because the user doesn't share a room with themselves yet.
|
| | | | | | | | | | | | | | |
|
|/ / / / / / / / / / / / /
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
m.room.member event in the 3rd party rules
|
|\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Implement new restrictions on power levels
|
| |\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
babolivier/power-levels
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
|
| |/ / / / / / / / / / / / / |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Since we're not processing only membership events and 3PID invites anymore, it's nice to know which function is supposed to process what.
|
| |/ / / / / / / / / / / / |
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
If we do the opposite, an event can arrive after or while sending the email and the 3PID invite event will get ratelimited.
|
|/ / / / / / / / / / / /
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
This would cause emails being sent, but Synapse responding with a 429 when creating the event. The client would then retry, and with bad timing the same scenario would happen again. Some testing I did ended up sending me 10 emails for one single invite because of this.
|
|\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Fix new 3PID bindings being associated with rewritten IS's server names instead of the original one
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
instead of the original one
This would make unbind requests fail because Synapse is using the server name it has in DB as destination_is to generate signature, and Sydent uses its own server name there when verifying it, so if a mismatch happens, which is the case if the name gets rewritten for routing purposes, the unbind requests fail on the signature verification.
|
| | | | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Port "Fix typo in deactivation background job" to dinsic
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
|/ / / / / / / / / / / / / |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ \ \
| | |_|_|_|_|_|_|_|/ / / /
| |/| | | | | | | | | | | |
Port "Fix 3PID invite room state over federation" to dinsic
|
| | |_|_|_|_|_|/ / / / /
| |/| | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Fixes that when a user exchanges a 3PID invite for a proper invite over
federation it does not include the `invite_room_state` key.
This was due to synapse incorrectly sending out two invite requests.
|
|\ \ \ \ \ \ \ \ \ \ \ \
| | |_|_|_|_|_|_|/ / / /
| |/| | | | | | | | | | |
|
| | |_|_|_|_|_|/ / / /
| |/| | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | |
|
|\| | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
babolivier/userdir_hide_users
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ \ \
| | |/ / / / / / / / / / /
| |/| | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \ \
| | | |_|/ / / / / / / / /
| | |/| | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | |/ / / / / / / / /
| | |/| | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \
| | | |_|_|_|_|_|/ / / /
| | |/| | | | | | | | | |
Fix bug sending federation transactions with lots of EDUs
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
If we try and send a transaction with lots of EDUs and we run out of
space, we call get_new_device_msgs_for_remote with a limit of 0, which
then failed.
|
| | | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \
| | | |/ / / / / / / / /
| | |/| | | | | | | | | |
Share an SSL context object between SSL connections
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
turns out we need a shiny version of service_identity to enforce this
correctly.
|
| | | | | | | | | | | | |
|
| | | | |_|/ / / / / /
| | | |/| | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This involves changing how the info callbacks work.
|
| | |\ \ \ \ \ \ \ \ \
| | | | |_|_|_|/ / / /
| | | |/| | | | | | |
| | | | | | | | | | | |
github.com:matrix-org/synapse into release-v1.0.0
|
| | | |/ / / / / / /
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Some keys are stored in the synapse database with a null valid_until_ms
which caused an exception to be thrown when using that key. We fix this
by treating nulls as zeroes, i.e. they keys will match verification
requests with a minimum_valid_until_ms of zero (i.e. don't validate ts)
but will not match requests with a non-zero minimum_valid_until_ms.
Fixes #5391.
|
| | |/ / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
It's not really a problem to trust notary responses signed by the old key so
long as we are also doing TLS validation.
This commit adds a check to the config parsing code at startup to check that
we do not have the insecure matrix.org key without tls validation, and refuses
to start without it.
This allows us to remove the rather alarming-looking warning which happens at
runtime.
|
| | | |_|_|/ / /
| | |/| | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | | |
fixes #5153
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Set default room version to v4.
|
| | |\ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Make a full SQL schema
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | |\ \ \ \ \ \ |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | |_|_|_|_|/
| | | |/| | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
identity server (#5377)
Sends password reset emails from the homeserver instead of proxying to the identity server. This is now the default behaviour for security reasons. If you wish to continue proxying password reset requests to the identity server you must now enable the email.trust_identity_server_for_password_resets option.
This PR is a culmination of 3 smaller PRs which have each been separately reviewed:
* #5308
* #5345
* #5368
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
There are a few changes going on here:
* We make checking the signature on a key server response optional: if no
verify_keys are specified, we trust to TLS to validate the connection.
* We change the default config so that it does not require responses to be
signed by the old key.
* We replace the old 'perspectives' config with 'trusted_key_servers', which
is also formatted slightly differently.
* We emit a warning to the logs every time we trust a key server response
signed by the old key.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Fixes some warnings, and a scary-looking stacktrace when sytest kills the
process.
|
| | |\ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
Fix get_max_topological_token to never return None
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
Make /sync return heroes if room name or canonical alias are empty
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
I probably should've just run autopep8 in the first place...
Signed-off-by: Katie Wolfe <katie@dnaf.moe>
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Signed-off-by: Katie Wolfe <katie@dnaf.moe>
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Fixes #4194
Signed-off-by: Katie Wolfe <katie@dnaf.moe>
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Fixes #4194
Signed-off-by: Katie Wolfe <katie@dnaf.moe>
|
| | |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Validate federation server TLS certificates by default.
|
| | | |\ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Include left members in room summaries' heroes
|
| | | | |_|_|/ / / / / / / /
| | | |/| | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
the joined members or the parted ones
|
| | |\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Implement room v5 which enforces signing key validity
|
| | | | |/ / / / / / / / / /
| | | |/| | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Implements [MSC2077](https://github.com/matrix-org/matrix-doc/pull/2077) and
fixes #5247 and #4364.
|
| | |\ \ \ \ \ \ \ \ \ \ \ \
| | | |_|_|/ / / / / / / / /
| | |/| | | | | | | | | | | |
Associate a request_name with each verify request, for logging
|
| | | |/ / / / / / / / / /
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Also:
* rename VerifyKeyRequest->VerifyJsonRequest
* calculate key_ids on VerifyJsonRequest construction
* refactor things to pass around VerifyJsonRequests instead of 4-tuples
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Previously, setting this option would cause an exception at startup.
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
* Update _matrix/client/versions to reference support for r0.5.0
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
* Fix background updates to handle redactions/rejections
In background updates based on current state delta stream we need to
handle that we may not have all the events (or at least that
`get_events` may raise an exception).
|
| | |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Fix handling of failures when calling /event_auth.
|
| | | | | | | | | | | | | | |
|
| | | | |_|_|_|/ / / / / /
| | | |/| | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
When processing an incoming event over federation, we may try and
resolve any unexpected differences in auth events. This is a
non-essential process and so should not stop the processing of the event
if it fails (e.g. due to the remote disappearing or not implementing the
necessary endpoints).
Fixes #3330
|
| | | |/ / / / / / / / /
| | |/| | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Improve documentation of monthly active user blocking and mau_trial_days
|
| | | |/ / / / / / / /
| | |/| | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Remove some spurious stuff, clarify some other stuff
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
it's a bit confusing
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Fixes a regression introduced in #5335.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
FederationClient.get_pdu is called in a loop to fetch a batch of PDUs. A
failure to fetch one should not result in a failure of the whole batch. Add the
missing `continue`.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
We have too many things called get_event, and it's hard to figure out what we
mean. Also remove some unused params from the signature, and add some logging.
|
| | |\ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
Make account validity renewal emails work when email notifs are disabled
|
| | |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Ignore room state with null bytes in for room stats
|
| | | | | | | | | | | | | |
|
| | | | |_|_|_|/ / / / /
| | | |/| | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
It takes at least 20 minutes to work through the long_retries schedule (11
attempts, each with a 60 second timeout, and 60 seconds between each request),
so if the notary server isn't returning within the timeout, we'll just end up
blocking whatever request is happening for 20 minutes.
Ain't nobody got time for that.
|