The check fetched the whole history of develop with all tags for every
pull request (about 250 MB), which was slow and loaded the git server.
Listing added files only needs the trees of the tip.
The limit was a connection parameter, so it applied to every GIN index
scan, not only full-text search: recipient lookups and Oban job queries
could return incomplete, random results. Set it with SET LOCAL around
the search query only, configurable under Pleroma.Search.DatabaseSearch.
The default stays 500 for search: measured on a 74M-object database,
higher limits or none make searches for common words exceed the query
timeout. Remote fetches for URL queries run outside the transaction.
Based on Akkoma 811f0a468.
Co-authored-by: Oneric <oneric@oneric.stub>
The peers query read the nickname of every remote user every minute
(2.7 s and 1.2M buffer hits on a large instance). The instances table
now has a row for every host we know users from, so read it instead,
and recompute the stats every 5 minutes.
Based on Akkoma 138b1aea2 and 7b76fdeed.
Co-authored-by: Oneric <oneric@oneric.stub>
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
The instances table only got rows from fetches, reachability changes
and favicon lookups, so most hosts we know users from had none. Insert
a row when a remote user is created, keeping existing rows.
Mastodon 4.4+ clients read quotes from a top-level quote object with
state and quoted_status; Pleroma only had pleroma.quote, so they did
not show quote posts. Quoted statuses get a shallow quote with only
quoted_status_id, as quotes are rendered one level deep.
Inspired by Akkoma 5b7209980, which can not use the shallow form because
Akkoma already had a top-level quote status.
Containment.get_actor raised on remote shapes it did not know, such as
an attributedTo object without an id. This crashed object fetches and
poll refetches. Return nil, so containment rejects the object.
A fetch from a display URL (e.g. https://host/@user) returns the
actor with its canonical id. make_user_from_ap_id looked the user up
by the fetch URL, did not find it and tried to insert a duplicate.
Look the user up by the fetched id.
Based on Akkoma 48b3a3579.
refetch_object (used for poll updates) accepted whatever the remote
served. A hostile server could swap in another object or move the post
to another author.
The refetch now goes to the stored id without redirects, and the
returned id and actor must equal the stored ones.
Based on Akkoma 9061d148b and fee57eb37.
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.
HTTPSignaturePlug checks the policy before the cryptographic check. A
signed GET that fails it counts as unsigned; the inbox answers 401 to a
POST that fails it instead of queueing a failed-signature retry, which
only re-checks the signature. signature_policy: :log only logs.
Based on Akkoma's HTTP signature hardening.
Signature.check_signature_policy/2 requires date or (created) to be
signed and within signature_max_age (2 h) / signature_max_clock_skew
(1 h), and requires a signed, hashed digest for requests with a body.
Based on Akkoma's http_signatures fork (required headers, max_sig_age)
and Mastodon's SignedRequest (clock skew margin).
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.
Followers-only posts and DMs went to each recipient's personal inbox,
so a followers-only post was sent once per follower on the same server.
Mastodon, GoToSocial and Iceshrimp.NET always use the shared inbox.
Only activities with bcc or bto still go to personal inboxes.
Based on Akkoma a80444041.
Co-authored-by: Oneric <oneric@oneric.stub>
Keyword.update/4 added filters: [] to a Pleroma.Upload ConfigDB entry
without a :filters key, which would hide the filters from the config
file, GPS stripping included. Only rewrite lists that change.
0.1.2 handles gridded HEIC photos (as iPhones write them), PNG files
with data after IEND and TIFF files, and bounds HEIC parsing by the
input size. Add tests for these files.
Old configs keep working and now also strip GPS from WebP and HEIC.
The deprecation warning names the replacement for each old filter, and
exiftool is no longer a startup requirement.
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)
