This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Query missing cross-signing keys on local sig upload #7289
Query missing cross-signing keys on local sig upload #7289
Changes from 24 commits
8348481
1063495
cc86457
c265bc7
39ed9f6
fd8d154
759b6b0
03d2c8c
b386658
bd9a671
745e653
f8b6f14
37ae643
83861c3
671178b
2d88b5d
f417300
2f87051
5990d1c
4f8ba5c
9240abc
3282423
95dd9d5
4f41f37
6d559ba
1b4dda5
7cb1e48
74eaac0
b08b7c7
de29d1f
8484a72
2932b9b
ebea2ee
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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'm afraid this still feels like spaghetti. Why are we returning key_id and verify_key from
_retrieve_cross_signing_keys_for_remote_user
if we immediately throw them away?how about:
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 suppose one wouldn't be if we trust the data in our database, which we probably should be.
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.
is it correct that we store it before we check that it can be parsed? (In short, is the data in the table supposed to have been validated or not? If not, we need to be careful when we extract it). What does the existing code do?
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.
Considering the above call from the database did not have a try/except, I believe we're operating on the assumption that the data in the database is valid.
Yes, we should validate this data in some way. Some level of such is done in
do_remote_query
:synapse/synapse/handlers/e2e_keys.py
Lines 236 to 248 in 461f01a
I'd hate to duplicate but that could be lifted and modified.
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.
Speaking of verification, one thing that's confusing me is that in the loop of
_retrieve_cross_signing_keys_for_remote_user
,remote_result
should look something like this:synapse/synapse/federation/transport/client.py
Lines 404 to 415 in fd8d154
Thus
key_content
should look something like:synapse/synapse/federation/transport/client.py
Lines 407 to 408 in fd8d154
And thus we should need to extract the
key_contents
from that dictionary before we pass it toget_verify_key_from_cross_signing_key
.And yet this PR works, so something isn't lining up here.
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.
Already, so my docstring update is incorrect, as the thing I actually get back from
query_client_keys
is in the form:Lemme update that.
In terms of verification, I think we just need to check the user_id matches the user we're querying for, and that there's a
keys
field under each*_keys
key.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.
Aaand I was looking at the output of
query_user_devices
, notquery_client_keys
. Have updated the right docstring now.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.
So to conclude, we now validate the key by checking it belongs to the right user, and has a valid
keys
key dict in it withget_verify_key_from_cross_signing_key
.