I've been offline for a while, so didn't see this originally, but I randomly came across things that seem to be in reaction to this now-removed post.
I fetched the body of the post from the modlog - I'll avoid reposting it here, but wish to respond to the concern that's the "first big one".
Let's imagine that your instance had a minor outage. During that time, a remote user has made a post that their instance is trying to make you aware of by POSTing it to your inbox. It possibly retries a few times, but eventually it gives up.
Now you're online again, and you're receiving Likes and Replies to a post you don't have. Or maybe one of your users has noticed it's missing, so plugged it into the Search box.
What happens now? Well, if your instance is running Lemmy, it fetches it from the original source. This is normal and expected behaviour, and it just a plain old boring GET request.
If - for example - the post was https://lemmy.ml/post/47524469, then you never received a signed Create from https://lemmy.ml/u/yogthos, or a signed Announce from https://lemmy.ml/c/programmerhumor - there's no cryptographic verification at all, but you've asked an instance about activity from one of its own actors, and if you don't trust what it's saying, then you've got much bigger problems.
This isn't any different from what PieFed was doing (as part of its inter-op with PeerTube).
PeerTube has a different federation model than Lemmy. Video channels are like communities in many respects, but if it receives a reply from a remote user to a local video, then instead of sending out signed Announce by the channel (as Lemmy would do), it just resends the original Create out to its followers, but signed by the instance's "Application" actor instead. This meant that these replies were failing signature verification checks, because the 'actor' in the ActivityPub JSON (something like https://example.social/user/alice) was different that the actor who signed the POST (something like https://tinkerbetter.tube/accounts/peertube).
If you wanted to do it 'properly', then first you'd have to have a way of storing Application actors in your database, then you'd have to dig into the request header and get the Signature keyID, and then once that verified, you'd want to make sure that the instance does indeed host the appropriate community. Alternatively, you can think "bollocks to that", and just fetch the content from https://example.social/ instead.
There seemed to be some concern that an attacker could set up evil.com and send an unsigned POST to a PieFed instance saying that https://evil.com/user/alice has made a post to https://evil.com/post/1 and instead of rejected it as unsigned, PieFed would fetch https://evil.com/post/1.
Well ... yeah? If you own evil.com, then you have all the keys for your users, so nothing is stopping you sending posts that are signed by them (it's not like users know their own private keys). As such, whatever you might want to return from a GET request to https://evil.com/post/1 is exactly what you could put in a signed POST request from https://evil.com/user/alice anyway. If you're a malicious user with their own server, then you can pollute the fediverse as much as you like, until you get defederated of course, but the relevant bit of PieFed code wasn't making it any easier for such people.
