Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/871

Merge pull request 'Use FEP-c16b: Formatting MFM functions' (#823) from ilja/akkoma:use_fep-c16b_formatting_mfm_functions into develop

Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/823

Merge branch 'develop' of https://akkoma.dev/AkkomaGang/akkoma into use_fep-c16b_formatting_mfm_functions

When note editing support was added, it was omitted to strip internal
fields from edited notes and their history.

This was uncovered due to Mastodon inlining the like count as a "likes"
collection conflicting with our internal "likes" list causing validation
failures. In a spot check with likes/like_count it was not possible to
inject those internal fields into the local db via Update, but this
was not extensively tested for all fields and avenues.

Similarly address normalisation did not normalise addressing in the
object history, although this was never at risk of being exploitable.

The revision history of the Pleroma MR adding edit support reveals
recusrive stripping was intentionally avoided, since it will end up
removing e.g. emoji from outgoing activities. This appears to still
be true. However, all current internal fields ("pleroma_interal"
appears to be unused) contain data already publicised otherwise anyway.
In the interest of fixing a federation bug (and at worst potential data
injection) quickly outgoing stripping is left non-recursive for now.

Of course the ultimate fix here is to not mix remote and internal data
into the same map in the first place, but unfortunately having a single
map of all truth is a core assumption of *oma's AP doc processing.
Changing this is a masive undertaking and not suitable for providing
a short-term fix.

We expect most requests to be made for the actual canonical ID,
so check this one first (starting without query headers matching the
predominant albeit spec-breaking version).

Also avoid unnecessary rerewrites of the digest header on each route
alias by just setting it once before iterating through aliases.

This matches behaviour prioir to the SigningKey migration
and the expected semantics of the http_signatures lib.
Additionally add a min interval paramter, to avoid
refetch floods on bugs causing incompatible signatures
(like e.g. currently with Bridgy)

Merge pull request 'Expose Port IO stats via Prometheus' (#869) from Oneric/akkoma:io-telemetry into develop

Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/869

We already got the key.

Fixes: AkkomaGang/akkoma issue 858

User updates broke with the migration to separate signing keys
since user data carries signing keys but we didn't allow the
association data to be updated.

In particular this avoids an unecessary roundtrip
over user_id when searching a key via its primary key_id

Previously there were mainly two attack vectors:
 - for raw keys the owner <-> key mapping wasn't verified at all
 - keys were retrieved with refetching allowed
   and only the top-level ID was sanitised while
   usually keys are but a subobject

This reintroduces public key checks in the user actor,
previously removed in 9728e2f8
but now adapted to account for the new mapping mechanism.

To allow reuse for adapted key validation logic

It’s no longer listed in the catalogue and
the git repo wasn't updated in over a year

Only possible if actor keys leaked first
thus log with alert level

There might be further debate about "emoji" vs "emojis" for the plural
but a grep shows the latter is already widely used in our codebase.

Notably at least two instances were not properly guarded from path
traversal attack before and are only now fixed by using SafeZip:

 - frontend installation did never check for malicious paths.
   But given a malicious froontend could already, e.g. steal
   all user tokens even without this, in the real world
   admins should only use frontends from trusted sources
   and the practical implications are minimal

 - the emoji pack update/upload API taking a ZIP file
   did not protect against path traversal. While atm
   only admins can use these emoji endpoints, emoji
   packs are typically considered "harmless" and used
   without prior verification from various sources.
   Thus this appears more concerning.

This will replace all the slightly different safety workarounds at
different ZIP handling sites and ensure safety is actually consistently
enforced everywhere while also making code cleaner and easiert to
follow.

Commit a924e117 bumped the
plug package to 1.16.0 which includes our upstream patch.

Resolves: https://akkoma.dev/AkkomaGang/akkoma/issues/734

Commit 9d2c558f bumped
to a mime package version including the upstream fix.

The question mark suffix already implies it being an indicator function

Merge pull request 'Improve stat queries and ReceiverWorker logic' (#862) from Oneric/akkoma:perf_tweaks_stats+jobs into develop

Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/862

The first collection page is (sometimes?) inlined
which caused crashes when attempting to log the fetch failure.
But there’s no need to fetch and we can treat it like the other inline collection