clear_config([:logger, :backends], [value]) leaves the :logger env key
behind which breaks a ConfigDB test where the :logger key shouldn't be
stored and set.
My instance has been having problems with push federation since
updating to v2.10.2, using the docker image. Posts are not reaching
their destination instance until some other interaction initiates a
fetch from source.
The logs contain lots of errors such as:
```
pleroma | 09:34:40.885 [notice] TLS :client: In state :wait_cert_cr at ssl_handshake.erl:2158 generated CLIENT ALERT: Fatal - Unsupported Certificate
pleroma | - {:key_usage_mismatch,
pleroma | {{:Extension, {2, 5, 29, 15}, true, [:keyCertSign, :cRLSign]},
pleroma | {:Extension, {2, 5, 29, 37}, false, [{1, 3, 6, 1, 5, 5, 7, 3, 1}]}}}
```
This erlang/OTP issue seems to be the same problem:
https://github.com/erlang/otp/issues/9208
The erlang version committed here was selected after discussion in the
merge request.
I have not noticed any federation problems with an image built from
this dockerfile.
Two related changes that ensure remote images render inline in timelines
instead of as clickable links.
reverse_proxy: always force inline for whitelisted content types
When `inline_content_types` is configured as a whitelist, the upstream's
`content-disposition` header used to be passed through unchanged. Some
origins send `content-disposition: attachment` for media we want
embedded, so the proxy now always emits `content-disposition: inline`
for whitelisted types (overriding the upstream header), deriving a
filename from `MIME.extensions/1` (e.g. `inline.gif`) so browsers have
something to use for "Save As". When the type has no known extension,
the bare token `inline` is emitted. The `inline_content_types: true`
(pass-through) and `:false` (always attachment) behaviours are
unchanged.
ActivityPub: sniff MIME type for extensionless/generic attachments
Some remotes (e.g. extensionless Cloudflare Images URLs) ship
attachments with no usable `mediaType` (missing, empty, or
`application/octet-stream`), which would render as links instead of
inline images. `AttachmentValidator.fix_media_type/1` now fetches the
first 8 KB of the URL and runs it through libmagic when the declared
type carries no real information. Only `image/*` results replace the
declared type; any other result, non-2xx response, transport error, or
exception yields `nil` and the original type is kept, so ingestion
never blocks and non-image media is never reclassified. Present real
types are left untouched (no fetch is attempted).
The new logic lives in `Pleroma.Web.ActivityPub.ObjectValidators.AttachmentTypeSniffer`.
Tests: comprehensive coverage of both changes, including a dedicated
suite for the sniffer covering happy paths, non-image bodies, HTTP
failures, raised exceptions, guard clauses, and verification that the
Range header is sent; AttachmentValidator tests for mimeType fallback,
empty-string mediaType, multi-URL sniffing, and HTTP-failure fallback;
ReverseProxy tests for inline_content_types `true`/`false`/custom
whitelists, bare-inline for types without a MIME extension, and
attachment_name handling.
The core feed reader issue was that RSS 2.0 <link> is a simple text
element and can only appear once per <item>.
By having multiple <link> tags with rel attributes, parsers were
getting confused and resolving entries to the wrong URL.
Now each item has exactly one <link>: the post URL. Everything else
uses valid <atom:link> or dedicated extension elements where
appropriate.
