*key isn't accepting our replies

[AtiusAmy]

I just tested this post:
https://social.atiusamy.com/notes/a14pwhgxpccp030w
You can see the like from my Bluesky account on the heart section, but not reply that I replied
https://bsky.app/profile/amyiscoolz.bsky.social/post/3lbzykgg4mc2v

Same thing happened here:
https://social.atiusamy.com/notes/a13zfrq5pccp02wd
You can see that they liked my post, however:
https://bsky.app/profile/chiefwritesbook.bsky.social/post/3lbxuegwats2c
They replied to me, I can't see that on my end

[snarfed]

Looks like Sharkey interop issues, or interop with your instance? Bridgy Fed POSTed the activity below for your reply to https://social.atiusamy.com/users/9pa2kavedh4b000l/inbox at 2024-11-28 13:18:51 UTC, signed with https://bsky.brid.gy/ap/did:plc:2tvmas2l6jvjtqfpuuor6ujo 's key, and got an HTTP 202 response.

{
  "@context": ["https://www.w3.org/ns/activitystreams"],
  "type": "Create",
  "id": "https://bsky.brid.gy/convert/ap/at://did:plc:2tvmas2l6jvjtqfpuuor6ujo/app.bsky.feed.post/3lbzykgg4mc2v#bridgy-fed-create",
  "actor": "https://bsky.brid.gy/ap/did:plc:2tvmas2l6jvjtqfpuuor6ujo",
  "published": "2024-11-28T21:18:50.051009+00:00",
  "object": {
    "type": "Note",
    "id": "https://bsky.brid.gy/convert/ap/at://did:plc:2tvmas2l6jvjtqfpuuor6ujo/app.bsky.feed.post/3lbzykgg4mc2v",
    "url": "https://fed.brid.gy/r/https://bsky.app/profile/did:plc:2tvmas2l6jvjtqfpuuor6ujo/post/3lbzykgg4mc2v",
    "content": "<p>Rip or Smith idk</p>",
    "contentMap": { "en": "Rip or Smith idk" },
    "published": "2024-11-28T21:18:47.742Z",
    "attributedTo": "https://bsky.brid.gy/ap/did:plc:2tvmas2l6jvjtqfpuuor6ujo",
    "inReplyTo": "https://social.atiusamy.com/notes/a14pwhgxpccp030w",
    "tag": [{
        "type": "Mention",
        "href": "https://social.atiusamy.com/users/9pa2kavedh4b000l"
      }],
    "to": ["https://www.w3.org/ns/activitystreams#Public"],
    "content_is_html": true
    "cc": [
      "https://social.atiusamy.com/users/9pa2kavedh4b000l",
      "https://www.w3.org/ns/activitystreams#Public",
      "https://social.atiusamy.com/users/9pa2kavedh4b000l/followers"
    ],
  },
  "to": ["https://www.w3.org/ns/activitystreams#Public"],
  "cc": [
    "https://social.atiusamy.com/users/9pa2kavedh4b000l",
    "https://www.w3.org/ns/activitystreams#Public",
    "https://social.atiusamy.com/users/9pa2kavedh4b000l/followers"
  ]
}

[AtiusAmy]

That's interesting, I'll test with other instance shortly. Right now I have exams for the next two weeks so that'll have to wait 🥲 Perhaps there will be other people who can help test it?

[snarfed]

No worries! #375 may also be related.

Tentatively closing for now, but feel free to reopen if it turns out to be something on our end!

[AtiusAmy]

One of my friends tested this and it seems to be broken on their instance as well, might be an issue with misskey-based things

https://sakurajima.social/notes/a17mc5mjmp
https://bsky.app/profile/emergencygg.sakurajima.social.ap.brid.gy/post/3lc5wk2lo2uj2

Might be how federation and replies work? Not sure

[snarfed]

Thanks @AtiusAmy! Reopening. We tracked this a while back in #375 (comment) and reported it to Misskey in misskey-dev/misskey#10963 , which I've updated. @AtiusAmy feel free to report to Sharkey too if you want!

[puppygirlhornypost]

Thanks @AtiusAmy! Reopening. We tracked this a while back in #375 (comment) and reported it to Misskey in misskey-dev/misskey#10963 , which I've updated. @AtiusAmy feel free to report to Sharkey too if you want!

Hi, sharkey contributor here. It'd be really helpful if anyone here could tell me what versions they're using of sharkey/misskey. I believe this could be related to a set of security patches we pushed (which made it upstream to misskey) to harden our activitypub parsing.

[AtiusAmy]

Currently I'm on 2024.9.4

Sakurajima.social is on 2024.10.0-dev

[puppygirlhornypost]

I run https://transfem.social which is using sharkey 2024.9.3 (a version with the AP security fixes and some hot fixes for rate limits to thwart resource exhaustion based denial of service attacks). My bridged account (fedi->bsky) is at https://bsky.app/profile/puppygirlhornypost2.transfem.social.ap.brid.gy. I can confirm replies do not work in this version. At least from what I can tell? https://transfem.social/@[email protected] transfem.social's page for all notes (incl. replies) is completely lacking for my bsky -> fedi bridged account. I'll talk to the rest of the sharkey developers about this.

[AtiusAmy]

Alright I posted an issue here in Sharkey's Repo here:

https://activitypub.software/TransFem-org/Sharkey/-/issues/827

Hopefully I formatted that correctly 😅

[warriordog]

Hi, Sharkey contributor here. This is likely due to a recent set of security patches that were applied to all Misskey forks. *Key now performs strict hostname checking for all activities, meaning that actors, activities, and objects must all exist on the same domain. Bridgy sometimes uses different hostnames for the ATP->AP bridge, which fails the security check and rejects the activity.

This could also relate to an issue where some of Bridgy's generated URLs are non-normalized, but still parseable. We worked around this in Sharkey by normalizing all remote URLs, but I'm unsure if any other forks have introduced that patch.

[puppygirlhornypost]

@snarfed After talking to other sharkey developers I've found out we already have a working fix for this. I was correct in the assumption it was related to our security fixes for parsing activitypub activities. https://activitypub.software/TransFem-org/Sharkey/-/issues/815 https://activitypub.software/TransFem-org/Sharkey/-/issues/815#note_8805 (this points out what's actually being caught up). Seems like we have a fix waiting to be merged in though https://activitypub.software/TransFem-org/Sharkey/-/merge_requests/773

[snarfed]

@warriordog @puppygirlhornypost thanks for the sleuthing, and the in-progress fix! I'm a bit surprised this was caused by the same-domain security fixes, unless they happened before June 2023? That's when we first reported this to at least Misskey: misskey-dev/misskey#10963 . No matter though!

Interesting to follow the details in that Sharkey issue, too. AP itself doesn't require that actor ids, inboxes, etc are on the same domain, but lots of fediverse software does. eg in https://activitypub.software/TransFem-org/Sharkey/-/issues/815, the complaint that inbox and sharedInbox are on different domains, while technically compliant in AP, is a pretty reasonable thing for Bridgy Fed to try to "fix."

url being on a separate domain from id though, that feels a bit more important to allow, at least in Bridgy Fed's case. url should generally only used as a human-usable link, not for eg key fetching or signature verification or anything else security-relevant, right? I don't quite know how to parse the "severe domain takeover vuln because of how we verify provenance" concern.

[warriordog]

@snarfed I think we still allow url to be on a different domain - it's only the federation-related fields that have extra security.

[puppygirlhornypost]

@snarfed I'm even more confused because I have an example on transfem.social of a reply to another instance federating over post patches. https://transfem.social/notes/a19hx9zdncpk2zaj (origin https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:5qyei5yh67fic7mb4qborn5a/post/3lcbab5vxe22b) (yes ignore the domain name). Invoking a manual curl request (curl -X GET -H 'Accept: application/activity+json' https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:5qyei5yh67fic7mb4qborn5a/post/3lcbab5vxe22b) yields me

{
  "@context": [
    "https://www.w3.org/ns/activitystreams"
  ],
  "attributedTo": "https://bsky.brid.gy/ap/did:plc:5qyei5yh67fic7mb4qborn5a",
  "content": "<p>you following through the bridge?</p>",
  "contentMap": {
    "en": "you following through the bridge?"
  },
  "content_is_html": true,
  "id": "https://bsky.brid.gy/convert/ap/at://did:plc:5qyei5yh67fic7mb4qborn5a/app.bsky.feed.post/3lcbab5vxe22b",
  "inReplyTo": {
    "id": "https://gaysex.cloud/notes/a19hhj7a7qhr0319",
    "url": "https://bsky.app/profile/did:plc:mgflc2hwqonaafnbb3xok6re/post/3lcb7le34bth2"
  },
  "published": "2024-12-01T18:25:24.937Z",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "type": "Note",
  "url": "https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:5qyei5yh67fic7mb4qborn5a/post/3lcbab5vxe22b"
}

Which makes me wonder... why are some replies federating but others not?

[Tamschi]

Just out of curiosity if I may: What was the reasoning behind matching host names for authorisation?

(I don't see any place where that would improve security, since everything to me seems to be safely authenticated through links or signatures already, but I can imagine a few useful scenarios where an actor and their activity aren't on the same domain for example.)

[warriordog]

Just out of curiosity if I may: What was the reasoning behind matching host names for authorisation?

(I don't see any place where that would improve security, since everything to me seems to be safely authenticated through links or signatures already, but I can imagine a few useful scenarios where an actor and their activity aren't on the same domain for example.)

In the general case: cache poisoning attacks. If an actor can federate an object with another instance's domain, then they can copy the ID of a real object and "replace" it on any instance that hasn't seen it yet.

It's a little different for inboxes, where the risk is more of reflected DoS. A malicious actor can point their inbox to another domain to force other instances to spam requests.

[Tamschi]

Makes sense, though I think in the former case the fix should be to key on owning actor and id. Domain checks invite too many compatibility problems there.
(Late-edit: That alone isn't enough to fully implement ActivityPub, though it may well be enough for a practical subset.)

The DDoS problem seems harder 🤔
Naively I would say gating on whether the Accept.Follow went through would work since that should prevent amplification and make reflection costly, but there are likely too many instances that reply with 202 without checking the addressee.

[snarfed]

We ended up talking about the cache poisoning question elsewhere.

Otherwise, apart from the url field, afaik Bridgy Fed activities and objects always have id, attributedTo, and actor on the same hostname, which should satisfy same-domain checks. Sounds like Sharkey has a bug fix here on the way. Is there anything else we need to fix or change in Bridgy Fed?

[snarfed]

Published the cache poisoning vulnerability in GHSA-37r7-jqmr-3472 . Huge thanks to @Tamschi and @warriordog for reporting and helping debug and mitigate it! And apologies to you two, I had a wrap-up comment typed up and ready to add there, but I didn't realize publishing it would lock comments there. Ah well.

[silverpill]

For future reference:

FEP-fe34: Origin-based security model

[snarfed]

Sounds like the main outstanding issue here is Sharkey's historical check that id, url, all collections, etc are on the exact same hostname (origin). We do that for bridged users, but not always for bot users. Sharkey relaxed that check in https://activitypub.software/TransFem-org/Sharkey/-/merge_requests/773 , but I'm not sure when that will be released, and other software has similarly strict checks, so I'll put the bot users' sharedInbox collection on the same hostname.

[snarfed]

^ Done, should be deployed in ~10m. endpoints.sharedInbox is now https://bsky.brid.gy/ap/sharedInbox. Here's the full new actor for @[email protected]; the only non-bsky.brid.gy hostnames are in url, alsoKnownAs, image/icon, and summary.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/security/v1",
    {
      "alsoKnownAs": {
        "@id": "as:alsoKnownAs",
        "@type": "@id"
      }
    }
  ],
  "type": "Service",
  "id": "https://bsky.brid.gy/bsky.brid.gy",
  "url": [
    "https://bsky.brid.gy/",
    "https://fed.brid.gy/"
  ]
  "alsoKnownAs": [
    "https://bsky.brid.gy/",
    "https://fed.brid.gy/"
  ],
  "summary": "<p><a href='https://fed.brid.gy/'>Bridgy Fed</a> bot user for <a href='https://bsky.social/'>Bluesky</a>. To bridge your fediverse account to Bluesky, follow this account. <a href='https://fed.brid.gy/docs'>More info here.</a><p>After you follow this account, it will follow you back. Accept its follow to make sure your fediverse posts get sent to the bridge and make it into Bluesky.<p>To ask a Bluesky user to bridge their account, DM their handle (eg snarfed.bsky.social) to this account.</p>",
  "endpoints": {
    "sharedInbox": "https://bsky.brid.gy/ap/sharedInbox"
  },
  "followers": "https://bsky.brid.gy/bsky.brid.gy/followers",
  "following": "https://bsky.brid.gy/bsky.brid.gy/following",
  "icon": {
    "name": "Bridgy Fed for Bluesky",
    "type": "Image",
    "url": "https://fed.brid.gy/static/bridgy_logo_square.jpg"
  },
  "image": [{
      "type": "Image",
      "url": "https://fed.brid.gy/static/bridgy_fed_banner.png"
    },
    {
      "name": "Bridgy Fed for Bluesky",
      "type": "Image",
      "url": "https://fed.brid.gy/static/bridgy_logo_square.jpg"
    }],
  "inbox": "https://bsky.brid.gy/bsky.brid.gy/inbox",
  "name": "Bridgy Fed for Bluesky",
  "outbox": "https://bsky.brid.gy/bsky.brid.gy/outbox",
  "preferredUsername": "bsky.brid.gy",
  "publicKey": {
    "id": "https://bsky.brid.gy/bsky.brid.gy#key",
    "owner": "https://bsky.brid.gy/bsky.brid.gy",
    "publicKeyPem": "..."
  }
}