Can't follow to or from GoToSocial #2794
Comments
|
Stack trace for searching for a GTS user from Bookwyrm: |
|
I'm not super familiar with the code, but it looks as though Bookwyrm is seeing the 401, correctly falling back to a signed request, but then getting a 406 since the signed request isn't what GTS expects. I'm going to open a issue in the GTS repo for that so we can get some feedback from them. |
This is the header described in the ActivityPub spec, which should fix some federation problems with GoToSocial and potentially other picky services. Related: bookwyrm-social#2794
This is the header described in the ActivityPub spec, which should fix some federation problems with GoToSocial and potentially other picky services. Related: bookwyrm-social#2794, superseriousbusiness/gotosocial#1676
This is the header described in the ActivityPub spec, which should fix some federation problems with GoToSocial and potentially other picky services. Related: bookwyrm-social#2794, superseriousbusiness/gotosocial#1676
|
I've put together a fix for just the hs2019 issue, where it will try to validate an hs2019 signature as sha256 and if that fails, try to validate it as sha512, and then throw the usual error. So Bookwyrm should be able to validate GoToSocial's signatures now. It still doesn't solve the whole problem, but I think I've figured out why GoToSocial isn't validating Bookwyrm's signatures! With that patch applied, I get the following on my test instance when trying to follow:
And when I hit that endpoint on the bookwyrm instance, I get the following JSON:
If GTS is looking for the exact ID in the JSON, that's probably where the communication is breaking down. I'm not familiar enough with the spec to say which side should be normalizing this, though I'd tend to go with the robustness principle and say that both should. |
|
@kvibber is right that we're using mismatched key ids and should fix it. I've got an almost-working fix, but unfortunately whilst testing that, another problem with mentions has surfaced so I need to work out what's going on with that. |
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.
|
Seeing the same issue when trying to POST a Follow activity to a users inbox from Mastodon 4.1.2 as well as my own server that uses activitypub-express 4.2.1. Example POST https://books.theunseen.city/user/bahuma20/inbox: {
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://mastodon.local/13218191-0689-4d45-8f3e-d9027c812959",
"type": "Follow",
"actor": "https://mastodon.local/users/bahuma20",
"object": "https://books.theunseen.city/user/bahuma20"
}Signature header: |
Describe the bug
GoToSocial can retrieve individual posts from Bookwyrm, and can retrieve a Bookwyrm user's profile, but it cannot follow that user.
Bookwyrm cannot retrieve a GoToSocial user's profile at all and displays an error message when I search for one.
To Reproduce
On a GoToSocial instance, search for a Bookwyrm user. Then try to follow them.
On a Bookwyrm instance, search for a GoToSocial user. You can search for my test account at @[email protected]
Expected behavior
The GTS user should be able to follow the Bookwyrm user and vice versa
Instance
bookwyrm.social
Additional context
Add any other context about the problem here.
Using GoToSocial 0.8.0-rc1 and bookwyrm.social.
Logs show both of the following are throwing back 401 Unauthorized HTTP responses:
GTS' POST request to https://bookwyrm.social/inbox
Bookwyrm's GET request to https://gts.keysmash.xyz/users/kelsonv
This looks very similar to a bug I fixed in Takahe where it was rejecting signatures whose algorithm had been obfuscated by labeling it as "hs2019", which GoToSocial does according to https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12
jointakahe/takahe#528
In the case of Takahe it was easy to just treat hs2019 as sha-256, since that's the only signature algorithm it accepts. I took a look at bookwyrm/signatures.py and I see Bookwyrm also supports incoming sha-512 signatures, so it'll be a bit more complicated than just adding
or algorithm == 'hs2019'in verify_digest.I can give this a try over the weekend and see if it works and fixes either (or both) issues.
The text was updated successfully, but these errors were encountered: