This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Creating new room with 3pid invite fails #5253
Comments
|
yeah. That's not ideal. |
|
This is what I see on my server: |
|
Possibly related to matrix-org/sydent#154 |
|
still a problem, for the record |
richvdh
changed the title
|
only seems to affect createRoom |
|
given that we can send 3pid invites reliably at other times, it feels like this ought to work. Next steps: try to figure out what is different between the invite and the createRoom flows to see why the latter fails when the former succeeds. |
|
Huh weirdly I cannot reproduce this. I wonder if my 3pid is too new (as is suggested in matrix-org/sydent#154?) |
|
I am also unable to reproduce this on my own homeserver with a bunch of different email addresses, including some mentioned here. I had a quick skim through the code upon @richvdh's suggestion of trying to find discrepancies between the endpoints, and I found that they both just call Looks like the exception occurs when the homeserver attempts to perform the deprecated v1 bind lookup on the identity server (if v2 hashed lookup failed). v1 still relies on signatures, and after receiving a lookup result, we call synapse/synapse/handlers/identity.py Lines 610 to 640 in e739b20 synapse/synapse/handlers/identity.py Lines 754 to 776 in e739b20 This then calls into I had a look in vector.im's sydent config, and the public key appears to have changed at some point some months ago. This would cause a discrepancy between the currently advertised public key, and the one used to sign old binds. I'm still checking internally whether this is the case - but if it is, I suppose the options we have are:
I'm partial to either 1 or 2. 3 would take spec work and doesn't seem worth it compared to the others. |
|
I can believe this only happens on 3pids of a certain age. I'm still a bit confused about why it works when inviting a 3pid to an existing room, but fails when creating a new room |
|
Updated stacktrace from |
|
ah, so the difference is that riot isn't supplying an The upshot of that is that I don't think your option 1 (Complete deprecation of the v1 lookup endpoint) is going to fix this: we'll already use the v2 endpoint where the client provides the parameters we need: if we don't have the parameters we need for v2, we have the choice between a broken v1 api and an absent v1 api. If the signing key on the sydent instance has really been rotated without using a new key ID, that is a matter of profound regret, but I guess the ship has sailed now. I'm not keen on re-signing them, especially if the signatures are redundant with v2. Question: if we're happy to use the v2 api without any signatures, why do we insist on a valid signature from the v1 api? what if we skip the signature validation? |
See also matrix-org/sydent#154. |
I've talked to @dbkr about this ages ago and remember the conclusion that it was an overly paranoid check, which is why it was eliminated from the v2 API. I wouldn't be adverse to removing the check in Synapse, and that is a very simple solution to this whole mess. The identity service spec could use some updates after this. |
cool. could you do that then please? |
anoadragon453
added a commit
that referenced
this issue
Aug 3, 2020
We've [decided](#5253 (comment)) to remove the signature check for v1 lookups. The signature check has been removed in v2 lookups. v1 lookups are currently deprecated. As mentioned in the above linked issue, this verification was causing deployments for the vector.im and matrix.org IS deployments, and this change is the simplest solution, without being unjustified. Implementations are encouraged to use the v2 lookup API as it has [increased privacy benefits](matrix-org/matrix-spec-proposals#2134).
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
When i try to add an existing user by clicking the plus-button in riot (https://riot.im/app/) and providing its email-address i get a quick lookup of that persons nickname. Then, when i submit i get
Steps to reproduce
Since the lookup works i also expect that the invite works. When i use the 3pid to invite the user it works flawlessly.
I can reproduce the behavior on my own instance, here are the logs - obfuscated
Version information
matrix.orgas well as own instancematrix.metaccount.deThe logs say
0.99.5.1the curl-request the template suggests (without grep, because its not in the response) says :
Docker-Container in a Compose-Stack
official image from docker.io/matrixdotorg/synapse:latest
The text was updated successfully, but these errors were encountered: