Tries fully-qualifying emoji when receiving them, by adding the emoji
variation sequence to the received reaction emoji.
This issue arises when other instance software, such as Misskey, tries
reacting with emoji that have unqualified or minimally qualified
variants, like a red heart. Pleroma only accepts fully qualified emoji
in emoji reactions, and refused those emoji. Now, Pleroma will attempt
to properly qualify them first, and reject them if checks still fail.
The list of TLS versions was added by
8bd2b6eb13 when hackney version was
pinned to 1.15.2. Later hackney version was upgraded
(166455c884) but the list of TLS
versions wasn't removed. From the hackney point of view, this list has
been replaced by the OTP defaults since 0.16.0
(734694ea4e24f267864c459a2f050e943adc6694).
It looks like the same issue already occurred before:
0cb7b0ea84.
A way to test this issue (where example.com is an ActivityPub site
which uses TLSv1.3 only):
$ PLEROMA_CONFIG_PATH=/path/to/config.exs pleroma start_iex
Erlang/OTP 22 [erts-10.7.2.16] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]
Erlang/OTP 22 [erts-10.7.2.16] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]
Interactive Elixir (1.10.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(pleroma@127.0.0.1)2> Pleroma.Object.Fetcher.fetch_and_contain_remote_object_from_id("https://example.com/@/Nick/")
{:error,
{:tls_alert,
{:protocol_version,
'TLS client: In state hello received SERVER ALERT: Fatal - Protocol Version\n'}}}
With this patch, the output is the expected one:
iex(pleroma@127.0.0.1)3> Pleroma.Object.Fetcher.fetch_and_contain_remote_object_from_id("https://example.com/@/Nick/")
{:error,
{:ok,
%{
"@context" => [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1",
%{
"Emoji" => "toot:Emoji",
"Hashtag" => "as:Hashtag",
"atomUri" => "ostatus:atomUri",
"conversation" => "ostatus:conversation",
"featured" => "toot:featured",
"focalPoint" => %{"@container" => "@list", "@id" => "toot:focalPoint"},
"inReplyToAtomUri" => "ostatus:inReplyToAtomUri",
"manuallyApprovesFollowers" => "as:manuallyApprovesFollowers",
"movedTo" => "as:movedTo",
"ostatus" => "http://ostatus.org#",
"sensitive" => "as:sensitive",
"toot" => "http://joinmastodon.org/ns#"
}
],
"endpoints" => %{"sharedInbox" => "https://example.com/inbox"},
"followers" => "https://example.com/@/Nick/followers",
"following" => nil,
"icon" => %{
"type" => "Image",
"url" => "https://example.com/static/media/[...].png"
},
"id" => "https://example.com/@/Nick/",
"inbox" => "https://example.com/@/Nick/inbox",
"liked" => nil,
"name" => "Nick",
"outbox" => "https://example.com/@/Nick/outbox",
"preferredUsername" => "Nick",
"publicKey" => %{
"id" => "https://example.com/@/Nick/#main-key",
"owner" => "https://example.com/@/Nick/",
"publicKeyPem" => "[...]
},
"summary" => "",
"type" => "Person",
"url" => "https://example.com/@/Nick/"
}}
A way to test the reverse proxy bits of this issue (where example.com allows TLSv1.3 only):
iex(pleroma@127.0.0.1)1> Pleroma.ReverseProxy.Client.Hackney.request("GET", "https://example.com", [], [])
{:error,
{:tls_alert,
{:protocol_version,
'TLS client: In state hello received SERVER ALERT: Fatal - Protocol Version\n'}}}
* rejected_shortcodes is defined as a list of strings in the
configuration description. As such, database-based configuration was
led to handle those settings as strings, and not as the actually
expected type, Regex.
* This caused each message passing through this MRF, if a rejected
shortcode was set and the emoji did not exist already on the instance,
to fail federating, as an exception was raised, swiftly caught and
mostly silenced.
* This commit fixes the issue by introducing new behavior: strings are
now handled as perfect matches for an emoji shortcode (meaning that if
the emoji-to-be-pulled's shortcode is in the blacklist, it will be
rejected), while still supporting Regex types as before.
When someone isn't a superuser any more, they shouldn't see the reporsts any more either.
Here we delete the report notifications from a user when that user gets updated from being a superuser to a non-superuser.
elixir gettext current does not fully support fallback to another language [0].
But it might in the future. We adapt it so that all languages in Accept-Language
headers are received by Pleroma.Web.Gettext. User.languages is now a comma-separated
list.
[0]: https://github.com/elixir-gettext/gettext/issues/303
For an example, here, zh is not supported, but zh_Hans and zh_Hant
are. If the user asks for zh, we should choose a variant for them
instead of fallbacking to default.
Some browsers (e.g. Firefox) does not allow users to customize
their language codes. For example, there is no zh-Hans, but only
zh, zh-CN, zh-TW, zh-HK, etc. This provides a workaround for
those users suffering from bad design decisions.
![https://example.com/static/media/[...].png](https://example.com/static/media/[...].png){kind=link}