aboutsummaryrefslogtreecommitdiff
path: root/lib
AgeCommit message (Collapse)Author
2022-08-02Add support for Image objectsfeatures/image-objectHaelwenn (lanodan) Monnier
2022-07-31Merge branch 'develop' into 'from/develop/tusooa/emit-move'tusooa
# Conflicts: # CHANGELOG.md # test/pleroma/user_test.exs
2022-07-31Use `duration` param for mute expiration durationmarcin mikołajczak
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
2022-07-28Merge branch 'fix/proper-emoji-qualification' into 'develop'Haelwenn
Emoji: implement full-qualifier using combinations See merge request pleroma/pleroma!3709
2022-07-28Merge branch 'from/upstream-develop/tusooa/2384-pagination' into 'develop'Haelwenn
Make mutes and blocks behave the same as other lists Closes #2384 See merge request pleroma/pleroma!3693
2022-07-27Emoji: apply recommended tail call changesHélène
Behavior matches previous code. Co-authored-by: Tusooa Zhu <tusooa@kazv.moe>
2022-07-26Emoji: split qualification variation into a moduleHélène
2022-07-25EmojiReactValidator: use new qualification methodHélène
2022-07-25Emoji: implement full-qualifier using combinationsHélène
This implements fully_qualify_emoji/1, which will return the fully-qualified version of an emoji if it knows of one, or return the emoji unmodified if not. This code generates combinations per emoji: for each FE0F, all possible combinations of the character being removed or staying will be generated. This is made as an attempt to find all partially-qualified and unqualified versions of a fully-qualified emoji. I have found *no cases* for which this would be a problem, after browsing the entire emoji list in emoji-test.txt. This is safe, and, sadly, most likely the sanest too.
2022-07-24EmojiReactValidator: fix emoji qualificationHélène
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. This commit contains changes to tests proposed by lanodan. Co-authored-by: Haelwenn <contact+git.pleroma.social@hacktivis.me>
2022-07-23Merge branch 'mute-expiration' into 'develop'tusooa
MastoAPI: Show mutes expiration date See merge request pleroma/pleroma!3682
2022-07-22Revert "Merge branch 'fix/emoji-react-qualification' into 'develop'"Haelwenn
This reverts merge request !3684
2022-07-22AttachmentValidator: fix_media_type/1 fallback to application/octet-streamHaelwenn (lanodan) Monnier
2022-07-22ArticleNotePageValidator: Fix when attachments are a Map (ie. owncast)Haelwenn (lanodan) Monnier
2022-07-21Merge branch 'birthday_fix' into 'develop'tusooa
Allow to unset birthday See merge request pleroma/pleroma!3702
2022-07-21Merge branch 'fix/emoji-react-qualification' into 'develop'Haelwenn
EmojiReactValidator: fix emoji qualification See merge request pleroma/pleroma!3684
2022-07-21Merge remote-tracking branch 'upstream/develop' into HEADTusooa Zhu
2022-07-20Merge branch 'resolve/notice-compatibility-routes-nginx' into 'develop'Haelwenn
Document way to do notice compatibility routes with Nginx reverse-proxy, fixes #2900 Closes #2900 See merge request pleroma/pleroma!3701
2022-07-17Allow to unset birthdaymarcin mikołajczak
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
2022-07-17Merge branch 'from/upstream-develop/tusooa/config-translatable' into 'develop'Haelwenn
Translatable config descriptions Closes pleroma-meta#65 See merge request pleroma/pleroma!3695
2022-07-16Document way to do notice compatibility routes with Nginx reverse-proxy insteadSean King
2022-07-17Merge branch 'notification_types' into 'develop'tusooa
MastoAPI: Use `types` for filtering notifications See merge request pleroma/pleroma!3648
2022-07-16Use :utc_datetimemarcin mikołajczak
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
2022-07-14Pass in msgctxt for config translation stringsTusooa Zhu
2022-07-13Fix compile errorTusooa Zhu
2022-07-13Make admin api use translated config descriptionsTusooa Zhu
2022-07-13Extract config descriptions for translationTusooa Zhu
2022-07-13Merge branch 'short-description' into 'develop'tusooa
Add short_description instance field Closes #2865 See merge request pleroma/pleroma!3651
2022-07-12Make mutes and blocks behave the same as other listsTusooa Zhu
2022-07-11Merge branch 'fix/case-sensitivity-restricted-nicknames-blacklisted-domains' ↵tusooa
into 'develop' Make checking blacklisted domains and restricted nicknames case-insensitive Closes #2894 and #2888 See merge request pleroma/pleroma!3687
2022-07-10Make lint happyTusooa Zhu
2022-07-10Merge branch 'from/upstream-develop/tusooa/2830-remote-fo-mp' into 'develop'Haelwenn
Pass remote follow avatar into media proxy Closes #2830 See merge request pleroma/pleroma!3690
2022-07-10Pass remote follow avatar into media proxyTusooa Zhu
2022-07-06Make validation functions for restricted nicknames and blacklisted domains; ↵Sean King
do restricted nickname validation in LDAP account registration
2022-07-05Make checking blacklisted domains and restricted nicknames case-insenstiveSean King
2022-07-03Merge branch 'image_description_from_exif_data' into 'develop'Haelwenn
Use EXIF data of image for image description See merge request pleroma/pleroma!3535
2022-07-03Merge branch 'bugfix/mime-validation-no-list' into 'develop'Haelwenn
Bugfix: Validate mediaType only by it's format See merge request pleroma/pleroma!3597
2022-07-03Merge branch 'from/upstream-develop/tusooa/server-announcements' into 'develop'Haelwenn
Server announcements (1st pass) See merge request pleroma/pleroma!3643
2022-07-01Descriptions from exif data with only whitespeces are considered emptyIlja
I noticed that pictures taken with Ubuntu-Touch have whitespace in one of the fields This should just be ignored imo
2022-07-01update moduledocIlja
2022-07-01Better way of getting keysIlja
I used keyword_list[:key], but if the key doesn't exist, it will return nil. I actually expect a list and further down the code I use that list. I believe the key should always be present, but in case it's not, it's better to return an empty list instead of nil. That way the code wont fail further down the line.
2022-07-01Add deprecation warningsIlja
2022-07-01Rename the Exiftool moduleIlja
No migrations or checks yet
2022-07-01Rename the new moduleIlja
2022-07-01Use EXIF data of image to prefill image descriptionIlja
During attachment upload Pleroma returns a "description" field. Pleroma-fe has an MR to use that to pre-fill the image description field, <https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1399> * This MR allows Pleroma to read the EXIF data during upload and return the description to the FE * If a description is already present (e.g. because a previous module added it), it will use that * Otherwise it will read from the EXIF data. First it will check -ImageDescription, if that's empty, it will check -iptc:Caption-Abstract * If no description is found, it will simply return nil, just like before * When people set up a new instance, they will be asked if they want to read metadata and this module will be activated if so This was taken from an MR i did on Pleroma and isn't finished yet.
2022-06-28EmojiReactValidator: fix emoji qualificationHélène
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.
2022-06-16Store mutes expiration datemarcin mikołajczak
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
2022-05-31hackney adapter helper & reverse proxy client: enable TLSv1.3Pierre-Louis Bonicoli
The list of TLS versions was added by 8bd2b6eb138ace3408a03c78ecc339fc35b19f10 when hackney version was pinned to 1.15.2. Later hackney version was upgraded (166455c88441b22455d996ed528ed4804514a3c0) 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: 0cb7b0ea8477bdd7af2e5e9071843be5b8623dff. 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'}}}
2022-05-18StealEmojiPolicy: fix String rejected_shortcodesHélène
* 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.
2022-05-08Merge branch 'improve_anti_followbot_policy' into 'develop'Haelwenn
Also use actor_type to determine if an account is a bot in antiFollowbotPolicy Closes #2561 See merge request pleroma/pleroma!3498