Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote ActivityPub actors with fragment identifiers (IRI) are not supported #2801

Closed
imitko opened this issue Apr 7, 2023 · 1 comment · Fixed by #2812
Closed

Remote ActivityPub actors with fragment identifiers (IRI) are not supported #2801

imitko opened this issue Apr 7, 2023 · 1 comment · Fixed by #2812
Labels
activitypub bug Something isn't working

Comments

@imitko
Copy link

imitko commented Apr 7, 2023

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

  1. 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.
  2. 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.

@imitko imitko added the bug Something isn't working label Apr 7, 2023
@hughrun
Copy link
Contributor

hughrun commented Apr 8, 2023

@WesleyAC I think this might be related to our GoToSocial problem. I'm going to take a look at this today.

hughrun added a commit to hughrun/bookwyrm that referenced this issue Apr 10, 2023
Fixes bookwyrm-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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
activitypub bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants