Occasionally we could get a federation device list update transaction which
looked like:
```
[
{'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D2', 'prev_id': [], 'stream_id': 12, 'deleted': True}},
{'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D1', 'prev_id': [12], 'stream_id': 11, 'deleted': True}},
{'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D3', 'prev_id': [11], 'stream_id': 13, 'deleted': True}}
]
```
Having `stream_ids` which are lower than `prev_ids` looks odd. It might work
(I'm not actually sure), but in any case it doesn't seem like a reasonable
thing to expect other implementations to support.
* master:
1.12.1
Note where bugs were introduced
1.12.1rc1
Newsfile
Rewrite changelog
Add changelog
Only import sqlite3 when type checking
Fix another instance
Only setdefault for signatures if device has key_json
Fix starting workers when federation sending not split out.
Attempt to clarify Python version requirements (#7161)
Improve the UX of the login fallback when using SSO (#7152)
Update the wording of the config comment
Lint
Changelog
Regenerate sample config
Whitelist the login fallback by default for SSO
===========================
No significant changes since 1.12.1rc1.
Synapse 1.12.1rc1 (2020-03-31)
==============================
Bugfixes
--------
- Fix starting workers when federation sending not split out. ([\#7133](https://github.com/matrix-org/synapse/issues/7133)). Introduced in v1.12.0.
- Avoid importing `sqlite3` when using the postgres backend. Contributed by David Vo. ([\#7155](https://github.com/matrix-org/synapse/issues/7155)). Introduced in v1.12.0rc1.
- Fix a bug which could cause outbound federation traffic to stop working if a client uploaded an incorrect e2e device signature. ([\#7177](https://github.com/matrix-org/synapse/issues/7177)). Introduced in v1.11.0.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEgQG31Z317NrSMt0QiISIDS7+X/QFAl6GAZMTHGFuZHJld0Bh
bW9yZ2FuLnh5egAKCRCIhIgNLv5f9JqOD/4kjIBwKSOaUzYhzaP+4o4fDwz49IiO
GzSgq6bf+C1V6Vev/7+N1is0FnbfelaJZHf7wM1044tozL+puPqaGl2A/Zjxs8Pf
x9LpS53yOBsYYUvvYSUdE8MlWPimV/EERJa9eoIKloMt2vtcNpwwE+KYygqPR6Rz
xvexnh5FwOj9zQAS3KDE+ZUbgrx+S+VkV6C5tlDziuOlT1VZBsGGj/SmfKX9d11z
e22hgebAaEKheACAEvrHzGl5JyR8fmAuBOSWRmybucyzAQRGNm4yqoOaonD8ic0l
CkbjC1ix5BdfP2vAww6wzWRDXSmU1qk8hC4/SXCaS/xH2RN5Jh9ptnw0tuWwP0dk
J8joNBGR3cOrDDwjnqguqE1fckLTa/JOxNy8JzVTugO0v1KmDk7kYuO6GOapNmXI
qUuqrQARTCsoAt6r5qMlyKw/yk4vjLdZ9VxRDtI4uz/P+WeWS4LTG8G9eMKjZ9Kd
rOaIlO7lA6vwFMd7Twe1p6y721yfhGyp6Jcz6UDOdh+cbxZ1fSg8/SsYA9NrbqOk
4bHt7s8YNI/V2kU+LxuZjtOFENa7XvsR/rURts2GvNGDusZJMNHl8aJvOCnF+ReO
M6Ayzx+91R3oRaRdmuuvwLdFStrnSfHp7XcZYOGvN8fUBocfB2c+yZR5H9MhWSnv
h1Gndj+lR7uvKg==
=/J/H
-----END PGP SIGNATURE-----
Merge tag 'v1.12.1'
Synapse 1.12.1 (2020-04-02)
===========================
No significant changes since 1.12.1rc1.
Synapse 1.12.1rc1 (2020-03-31)
==============================
Bugfixes
--------
- Fix starting workers when federation sending not split out. ([\#7133](https://github.com/matrix-org/synapse/issues/7133)). Introduced in v1.12.0.
- Avoid importing `sqlite3` when using the postgres backend. Contributed by David Vo. ([\#7155](https://github.com/matrix-org/synapse/issues/7155)). Introduced in v1.12.0rc1.
- Fix a bug which could cause outbound federation traffic to stop working if a client uploaded an incorrect e2e device signature. ([\#7177](https://github.com/matrix-org/synapse/issues/7177)). Introduced in v1.11.0.
* tag 'v1.12.1':
1.12.1
Note where bugs were introduced
1.12.1rc1
Newsfile
Rewrite changelog
Add changelog
Only import sqlite3 when type checking
Fix another instance
Only setdefault for signatures if device has key_json
Fix starting workers when federation sending not split out.
This broke in a recent PR (#7024) and is no longer useful due to all
replication clients implicitly subscribing to all streams, so let's
just remove it.
If there was an exception setting up one of the attributes of the Homeserver
god object, then future attempts to fetch that attribute would raise a
confusing "Cyclic dependency" error. Let's make sure that we clear the
`building` flag so that we just get the original exception.
Ref: #7169
* Remove `conn_id` usage for UserSyncCommand.
Each tcp replication connection is assigned a "conn_id", which is used
to give an ID to a remotely connected worker. In a redis world, there
will no longer be a one to one mapping between connection and instance,
so instead we need to replace such usages with an ID generated by the
remote instances and included in the replicaiton commands.
This really only effects UserSyncCommand.
* Add CLEAR_USER_SYNCS command that is sent on shutdown.
This should help with the case where a synchrotron gets restarted
gracefully, rather than rely on 5 minute timeout.
In particular, we depend on `typing.TYPE_CHECKING`, which is only present in
3.5.2.
It turns out that Ubuntu Xenial, despite having a package called `python 3
(3.5.1-3)`, actually has python 3.5.2, so I think this is fine.
That fallback sets the redirect URL to itself (so it can process the login
token then return gracefully to the client). This would make it pointless to
ask the user for confirmation, since the URL the confirmation page would be
showing wouldn't be the client's.
* Don't show the login forms if we're currently logging in with a
password or a token.
* Submit directly the SSO login form, showing only a spinner to the
user, in order to eliminate from the clunkiness of SSO through this
fallback.
* change debian package from python3-virtualenv to virtualenv
The virtualenv package is needed for the virtualenv command. The
virtualenv package depends on python3-virtualenv (at least since
debian jessie) so there is no need to specify python3-virtualenv
additionally.
Signed-off-by: Vieno Hakkerinen <vieno@hakkerinen.eu>
* Add changelog
Co-authored-by: Andrew Morgan <andrew@amorgan.xyz>
* Don't show the login forms if we're currently logging in with a
password or a token.
* Submit directly the SSO login form, showing only a spinner to the
user, in order to eliminate from the clunkiness of SSO through this
fallback.
