The fetcher accepted any document whose id was on the same host as the
fetch URL. Anyone who can place a JSON file on a host, for example
through an upload, could pass it off as another object or actor from
that host.
The id of a fetched document must now be the URL it came from (after
redirects), ignoring a trailing slash, the fragment, the host case and
differences that our URL encoding removes.
If it differs, as for Mastodon's /@user/123 display URLs, we refetch
once from that id, which must be on the same host. The refetch must
not redirect and must match exactly.
Test mocks that served a document under a different URL now serve it
from its own id.
Based on Akkoma 8684964c5 and 940792f8b.
A remote actor could set its inbox or shared inbox to a third-party
host, so our signed deliveries went there. It could also claim
another actor's followers collection, which the visibility checks
trust.
Validate fetched actors and incoming actor Updates: inbox,
endpoints.sharedInbox, followers, following, featured and the
publicKey id must be on the same host as the actor id.
Based on Akkoma f07eb4cb5. The Bridgy fixture gets the key id that
current Bridgy Fed serves.
Some peertube videos are federated with explicitly zero dimensions
for their mp4 link leading to a division-by-zero exception here.
E.g.: https://spectra.video/videos/watch/66c12674-2013-47a4-9126-51ff8eb8d0a8
(as of writing using peertube 8.1.1)
Reported by temp3 on IRC
(cherry picked from commit 6833281051aa86b3d82232be29497fed47bf5fb1)
User.Query ignores is_active. The friends subquery already drops
deactivated users here, so this only removes the last ignored key.
Also add a changelog entry and a test.
While "is_active" is a property of users, it is not a recognised keyword
for the User.Query helper; instead "deactivated" with negated value must
be used.
This arose because originally the user property was also called
"deactivated" until it was renamed adn negated five years ago
in 860b5c7804. This included renaiming
the parameter in most but not all User.Query usages.
Notably the parameter in User.get_followers_query was renamed
but not in User.get_friends_query (friends == following).
The accepted query parameter in User.Query however was not changed.
This lead to the former mistakenly including deleted users causing
too large values to be reported in the ActivityPub follower, but not
following collection as reported in #1078.
In Masto API responses filtering by `User.is_visible` weeded out
the extra accounts before they got displayed to API users.
On the surface it might seem logical to align the name of the User.Query
parameter with the actual property name. However, User.Query already
accepts an "active" parameter which is an alias for limiting to accounts
which are neither deleted nor deactivated by moderators (both indicated
by is_active) and also are not newly created account requests still
pending an admin approval (is_approved) or necessary email confirmation
(is_confirmed); in short as the alias suggests whether the account is
active. Two highly similar parameter names like this would be much too
confusing.
The renamed "is_active" on the other hand does not actually suffice to
say whether an account is actually active, only whether it has (not yet)
ceased to be active (by its own volition or moderator action).
Meaning its "new" name is actively misleading. Arguably the rename
made things worse for no reason whatsoever and should not ever have
happened.
For now, we’ll just revert the incorrect query helper parameter renames.
Fixes: https://akkoma.dev/AkkomaGang/akkoma/ issues/ 1078
(cherry picked from commit a899663ddc0e3a2084a239eabd79608a94ac5493)
The bucket entry expires one window after the first request. With a 50
or 80 ms window, a slow CI run could lose it between two requests, so
inspect_bucket/3 returned {0, 5} (seen on #8021 with Elixir 1.17). The
reset test expires the bucket itself, so a long window costs nothing.
Regex.match? raised on objects without content (for example posts with
only attachments), so no notifications were created for them when the
recipient had an irreversible filter.
Delivery jobs only checked reachability, so a job queued (or retrying)
before the admin rejected or quarantined an instance was still sent.
Check should_federate? again when the job runs.
The whole_word field was stored and returned by the API, but the regex
always used word boundaries. As in Mastodon, a filter with whole_word
false now also matches inside words.
The access check from the previous commit crashed on tags of unknown
users in followers-only posts, so such posts failed to be received.
Also add tests for the check.
Public activities went to every inbox, so followers on an instance in
the SimplePolicy reject list still got our posts. With authorized fetch
mode on, signed fetches from those instances were also accepted, unless
the instance was in :instance, :rejected_instances too.
Check the SimplePolicy reject and accept lists for deliveries and signed
fetches, when the policy is enabled. Quarantine keeps its meaning (no
private activities). An inbox without a host no longer crashes.
Based on the Akkoma changes 90c4785b8, ca000f830, 03662501c and d2b0d8647.
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Co-authored-by: Atsuko Karagi <atsuko.karagi@localhost>
Phrases went into the Postgres and Elixir regexes as they were, so a
phrase like "(" broke the timeline and notification queries. The :re
form also put the word boundaries only around the whole alternation.
Escape each phrase and, as Mastodon does, add a word boundary only where
the phrase starts or ends with a word character.
Reported in Akkoma (d6209837b).
Known implementations all intend to only tag users who are _also_ allowed to access the post,
but this is not guaranteed by ActivityPub semantics, thus recheck against the authorative
AP addressing fields.
An alternative worth considering is directly using the addressing fields to decide whom
to notify ignoring tags. However, MastoAPI later uses tags and thus this may lead to
confusing results if a recipient is addressed but not tagged and receives a notification about
being mentioned while the API claims they are not mentioned.
Addresses the receiving side of: https://akkoma.dev/AkkomaGang/akkoma/issues/1135
(cherry picked from commit 5cff1fac24bb3e6c22160202a7b846f8a62f2477)
Current logic unconditionally adds public adressing to "cc"
and follower adressing to "to" after attempting to strip it
from the other one. This creates serious problems:
First the bug prompting this investigation and fix,
unconditional addition creates duplicates when adressing
URIs already were in their intended final field; e.g.
this is prominently the case for all "unlisted" posts.
Since List.delete only removes the first occurence,
this then broke follower-adress stripping later on
making the policy ineffective.
It’s also just not safe in general wrt to non-public adressing:
e.g. pre-existing duplicates didn’t get fully stripped,
bespoke adressing modes with only one of public addressing
or follower addressing are mangled — and most importantly:
any belatedly received DM or follower-only post
also got public adressing added!
Shockingly this last point was actually asserted as "correct" in tests;
it appears to be a mistake from mindless match adjustments
while fixing crashes on nil adressing in
10c792110e.
Clean up this sloppy logic up, making sure no more duplicates are
added by us, all instances of relevant adresses are purged and only
readded when they actually existed to begin with.
(cherry picked from commit 932810c35ecba9d11fa4f11112c3444b62c45b65)
Hackney 4.9 enforces max_body while it reads and returns
{:error, {:closed, partial}} for a truncated body; the hackney
regression tests now pin that. The certifi override goes, as
hackney itself now asks for certifi ~> 2.18.0.
The C2S routes and the outbox/followers/following/replies collections
accepted a token with any scope. Requests with an OAuth token now need
the matching scope; HTTP signatures and Basic auth are not changed.
A token with only the profile scope can call verify_credentials, as in
Mastodon 4.3. The answer is the public account, so apps can use it to
log users in without seeing their email or settings.
