f8db412af4When the object associated with the activity was preloaded (which happens automatically with Activity.normalize used in the controller) Object.normalize’s "id_only" option did not actually work. This option and it’s usage were introduced to fix display of Undo activities in e88f36f72b5317debafcc4209b91eb35ad8f0691. For "Undo"s (and "Delete"s) there is no object preloaded (since it is already gone from the database) thus this appeared to work and for the particular case considered there in fact did. Create activities use different rendering logic and thus remained unaffected too. However, for all other types of Activities (yes, including Update which really _should_ include a properly sanitised, full object) this new attempt at including "just the id", lead to it instead including the full, unsanitised data of the referenced object. This is obviously bad and can get worse due to access restrictions on the activity being solely performed based on the addressing of the activity itself, not of the (unintentionally) embedded object. Starting with the obvious, this leaks all "internal" fields but as already mentioned in 8243fc0ef482a28daf2bcae2c64a9510bdb76489 all current "internal" fields from Constants.object_internal_fields are already publicised via MastoAPI etc anyway. Assuming matching addressing of the referenced object and activity this isn't problematic with regard to confidentiality. Except, the internal "voters" field recording who voted for a poll is currently just omitted from Constants.object_internal_fields and indeed confidential information (fix in subsequent commit). Fortunately this list is for the poll as a whole and there are no inlined lists for individual choices. While this thus leaks _who_ voted for a poll, it at least doesn't directly expose _what_ each voter chose if there are multiple voters. As alluded to before, the access restriction not being aware of the misplaced object data into account makes the issue worse. If the activity addressing is not a subset of the referenced object’s addressing, this will leak private objects to unauthorised users. This begs the question whether such mismatched addressing can occur. For remote activities the answer is ofc a resounding YES, but we only serve local ActivityPub objects and for the latter it currently(!) seems like a "no". For all intended interactions, the user interacting must already have access to the object of interest and our ActivityPub Builder already uses a subset of the original posts addressing for posts not publicly accessible. This addressing creation logic was last touched six years ago predating the introduction of this exposure blunder. The rather big caveat her being, until it was fixed just yesterday in dff532ac723310903e58c5d28f897cc2d116594f it was indeed possible to interact with posts one is not allowed to actually see. Combined, this allowed unauthorised access to private posts. (The API ID of such private posts can be obtained e.g. from replies one _is_ allowed to see) During the time when ActivityPub C2S was supported there might have been more ways to create activities with mismatched addressing and sneak a peek on private posts. (The AP id can be obtained in an analogous way) Replaces and fixes e88f36f72b5317debafcc4209b91eb35ad8f0691. Since there never were any users of the bugged "id_only" option it is removed. This was reported by silverpill <silverpill@firemail.cc> as an ActivityPub interop issue, since this blunder of course also leads to invalid AP documents by adding an additional layer in form of the "data" key and directly exposing the internal Pleroma representation which is not always identical to valid AP. Fixes: https://akkoma.dev/AkkomaGang/akkoma/issues/1017 |
||
|---|---|---|
| .gitlab | ||
| benchmarks | ||
| changelog.d | ||
| ci | ||
| config | ||
| docs | ||
| installation | ||
| lib | ||
| priv | ||
| rel | ||
| restarter | ||
| supplemental/search/fastembed-api | ||
| test | ||
| tools | ||
| .buildpacks | ||
| .credo.exs | ||
| .dialyzer_ignore.exs | ||
| .dockerignore | ||
| .formatter.exs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .rgignore | ||
| AGPL-3 | ||
| CC-BY-4.0 | ||
| CC-BY-SA-4.0 | ||
| CHANGELOG.md | ||
| COPYING | ||
| coveralls.json | ||
| docker-entrypoint.sh | ||
| Dockerfile | ||
| elixir_buildpack.config | ||
| mix.exs | ||
| mix.lock | ||
| Procfile | ||
| README.md | ||
| SECURITY.md | ||
About
Pleroma is a microblogging server software that can federate (= exchange messages with) other servers that support ActivityPub. What that means is that you can host a server for yourself or your friends and stay in control of your online identity, but still exchange messages with people on larger servers. Pleroma will federate with all servers that implement ActivityPub, like Friendica, GNU Social, Hubzilla, Mastodon, Misskey, Peertube, and Pixelfed.
Pleroma is written in Elixir and uses PostgresSQL for data storage. It's efficient enough to be ran on low-power devices like Raspberry Pi (though we wouldn't recommend storing the database on the internal SD card ;) but can scale well when ran on more powerful hardware (albeit only single-node for now).
For clients it supports the Mastodon client API with Pleroma extensions (see the API section on https://docs-develop.pleroma.social).
Installation
OTP releases (Recommended)
If you are running Linux (glibc or musl) on x86/arm, the recommended way to install Pleroma is by using OTP releases. OTP releases are as close as you can get to binary releases with Erlang/Elixir. The release is self-contained, and provides everything needed to boot it. The installation instructions are available here.
From Source
If your platform is not supported, or you just want to be able to edit the source code easily, you may install Pleroma from source.
- Alpine Linux
- Arch Linux
- CentOS 7
- Debian-based
- Debian-based (jp)
- FreeBSD
- Gentoo Linux
- NetBSD
- OpenBSD
- OpenBSD (fi)
OS/Distro packages
Currently Pleroma is packaged for YunoHost, NixOS, Gentoo through GURU and Archlinux through AUR. You may find more at https://repology.org/project/pleroma/versions.
If you want to package Pleroma for any OS/Distros, we can guide you through the process on our community channels. If you want to change default options in your Pleroma package, please discuss it with us first.
Docker
While we don’t provide docker files, other people have written very good ones. Take a look at https://github.com/angristan/docker-pleroma or https://glitch.sh/sn0w/pleroma-docker.
Raspberry Pi
Community maintained Raspberry Pi image that you can flash and run Pleroma on your Raspberry Pi. Available here https://github.com/guysoft/PleromaPi.
Compilation Troubleshooting
If you ever encounter compilation issues during the updating of Pleroma, you can try these commands and see if they fix things:
mix deps.clean --allmix local.rebarmix local.hexrm -r _build
If you are not developing Pleroma, it is better to use the OTP release, which comes with everything precompiled.
Documentation
- Latest Released revision: https://docs.pleroma.social
- Latest Git revision: https://docs-develop.pleroma.social
Community Channels
- IRC: #pleroma and #pleroma-dev on libera.chat, webchat is available at https://irc.pleroma.social
- Matrix: #pleroma:libera.chat and #pleroma-dev:libera.chat