You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A remote fediverse actor with URL fragment identifier can be searched and even asked to follow but BookWyrm reject 'Accept' and other incoming activities with http/401, note the remote proven to communicate with Mastodon and Pixelfed based instances (for example).
An example actor could be tried is http://fediverse.demo.openlinksw.com/dataspace/person/demo#this identifier @[email protected]
The problem boils down to following code in signature verification:
bookwyrm/views/inbox.py
134 key_actor = urldefrag(signature.key_id).url
135 if key_actor != activity.get("actor"): # <<< [1]
136 raise ValueError("Wrong actor created signature.")
137
138 remote_user = activitypub.resolve_remote_id(key_actor, model=models.User) # <<< [2]
139 if not remote_user:
140 return False
The keyId is not mandatory to be a same path as actor, it is common to be in same document, but actor is not a document URL.
Person/Organization etc. objects are not documents, therefore these can have fragment identifiers.
Expected flow:
Resolve the document based on keyId, look at publicKey/owner relation and compare with actor, if so use publicKeyPem to construct crypto key for verification, perhaps can cache the keyId publicKey/id from user profile and look for it.
Version is main branch on Github but fails with old versions as well.
The text was updated successfully, but these errors were encountered:
Fixesbookwyrm-social#2801
Related to bookwyrm-social#2794
It is legitimate to use any url for the user's key id. We have been assuming this id is the user id plus a fragment (#key-id) but this is not always the case, notably in the case of GoToSocial it is at /key-id. This commit instead checks the remote user's information to see if the key id listed matches the key id of the message allegedly received from them.
Whilst troubleshooting this it also became apparent that there is a mismatch between Bookwyrm users' keyId and the KeyId we claim to be using in signed requests (there is a forward slash missing). Since everything after the slash is a fragment, this usually slips through but we should be consistent so I updated that.
A remote fediverse actor with URL fragment identifier can be searched and even asked to follow but BookWyrm reject 'Accept' and other incoming activities with http/401, note the remote proven to communicate with Mastodon and Pixelfed based instances (for example).
An example actor could be tried is
http://fediverse.demo.openlinksw.com/dataspace/person/demo#this
identifier@[email protected]
The problem boils down to following code in signature verification:
bookwyrm/views/inbox.py
Expected flow:
Resolve the document based on
keyId
, look at publicKey/owner relation and compare with actor, if so use publicKeyPem to construct crypto key for verification, perhaps can cache the keyId publicKey/id from user profile and look for it.Version is main branch on Github but fails with old versions as well.
The text was updated successfully, but these errors were encountered: