===========================
Due to the two security issues highlighted below, server administrators are
encouraged to update Synapse. We are not aware of these vulnerabilities being
exploited in the wild.
Security advisory
-----------------
* A malicious homeserver could force Synapse to reset the state in a room to a
small subset of the correct state. This affects all Synapse deployments which
federate with untrusted servers. ([96e9afe6](96e9afe625))
* HTML pages served via Synapse were vulnerable to clickjacking attacks. This
predominantly affects homeservers with single-sign-on enabled, but all server
administrators are encouraged to upgrade. ([ea26e9a9](ea26e9a98b))
This was reported by [Quentin Gliech](https://sandhose.fr/).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEF3tZXk38tRDFVnUIM/xY9qcRMEgFAl799QkACgkQM/xY9qcR
MEhKzQ/+JJCbIuaymKQuyZRRt4b2ylXmMjfM8LpYgwk1vEUN2z+NNt4pmbFQtvdJ
Q1unHToDIK8b080DMagAc55MEF8GRtl8D411iGgSDeI/AqgVnsBTOW1cd7gDc0LC
eEs3jwnL5TYDeZYZUGqu+OfoPbdGnUX8ywQYTXk8y0njELwnoJdMuHSMq8kgsMur
eQ1cryevidpJiDQZlZFJQzlGoMrr4Aq94BZHooXfAdJnwCoIR/EVW4iie8GKSaNa
OT5tVYg8l4KzBOWZBrtXeeIKVNh7HHie8aJRJVXAGq/3vAEDT8HTAxPNJ6Ru4DA9
2VrflzmuRl9phxybfq2m1G1AvNkOlKu67e21YTSKK9EG/52VJoSXzKEeP9hdMfj5
v/Xfm7v1WqolukZZMc9zyleCoAK2Znu32/0/PYGsgw/vX7wGoCORdP22/vVfuCni
ZpUkZPlCA5XyD4QAyegzTVlp94IRI5oCErl6v1mESAaSkKyaGZ5jejTFWzOsKMuo
TpyCLLz6ZKLCtxsU6e7nGwDV7dX2iztq8fGf9+8lFsdXCbdI0YsyzAE8reehK9lL
rYxzl7fV+m6kzYg+pu3bfjH/YYgkPTvnV4juCOT/LQV7P3sEJAQrYBceIpAzyuS7
t0kCWTfX4UDrt1XbouuWJnvIHAFOG5/o/BEyhkQmW1c3GvDe8Jo=
=QQ4B
-----END PGP SIGNATURE-----
Merge tag 'v1.15.2'
Synapse 1.15.2 (2020-07-02)
===========================
Due to the two security issues highlighted below, server administrators are
encouraged to update Synapse. We are not aware of these vulnerabilities being
exploited in the wild.
Security advisory
-----------------
* A malicious homeserver could force Synapse to reset the state in a room to a
small subset of the correct state. This affects all Synapse deployments which
federate with untrusted servers. ([96e9afe6](96e9afe625))
* HTML pages served via Synapse were vulnerable to clickjacking attacks. This
predominantly affects homeservers with single-sign-on enabled, but all server
administrators are encouraged to upgrade. ([ea26e9a9](ea26e9a98b))
This was reported by [Quentin Gliech](https://sandhose.fr/).
Fixes https://github.com/matrix-org/synapse/issues/7683
Broke in: #7649
We had a `yield` acting on a coroutine. To be fair this one is a bit difficult to notice as there's a function in the middle that just passes the coroutine along.
* Ensure account data stream IDs are unique.
The account data stream is shared between three tables, and the maximum
allocated ID was tracked in a dedicated table. Updating the max ID
happened outside the transaction that allocated the ID, leading to a
race where if the server was restarted then the same ID could be
allocated but the max ID failed to be updated, leading it to be reused.
The ID generators have support for tracking across multiple tables, so
we may as well use that instead of a dedicated table.
* Fix bug in account data replication stream.
If the same stream ID was used in both global and room account data then
the getting updates for the replication stream would fail due to
`heapq.merge(..)` trying to compare a `str` with a `None`. (This is
because you'd have two rows like `(534, '!room')` and `(534, None)` from
the room and global account data tables).
Fix is just to order by stream ID, since we don't rely on the ordering
beyond that. The bug where stream IDs can be reused should be fixed now,
so this case shouldn't happen going forward.
Fixes#7617
While working on https://github.com/matrix-org/synapse/issues/5665 I found myself digging into the `Ratelimiter` class and seeing that it was both:
* Rather undocumented, and
* causing a *lot* of config checks
This PR attempts to refactor and comment the `Ratelimiter` class, as well as encourage config file accesses to only be done at instantiation.
Best to be reviewed commit-by-commit.
Calls `self.get_success` on all deferred methods instead of abusing `self.pump()`. This has the benefit of working with coroutines, as well as checking that method execution completed successfully.
There are also a few small cleanups that I made in the process.
* Expose `return_html_error`, and allow it to take a Jinja2 template instead of a raw string
* Clean up exception handling in SAML2ResponseResource
* use the existing code in `return_html_error` instead of re-implementing it
(giving it a jinja2 template rather than inventing a new form of template)
* do the exception-catching in the REST layer rather than in the handler
layer, to make sure we catch all exceptions.
