Home | Notifications | New Note | Local | Federated | Search | Logout

Federated Timeline


Nova@Chishiki611@enby.life boosted: @fedify@hollo.social (2026-05-21 02:35:44) Fedify security updates: 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3
If you use Fedify, update to a patched release now. CVE-2026-42462 affects Fedify's Linked Data Signature handling. An attacker could use JSON-LD graph-restructuring features to change how a signed activity is interpreted without invalidating its Linked Data Signature.

Fedify verifies incoming ActivityPub activities with several mechanisms, including HTTP Signatures, Object Integrity Proofs, and Linked Data Signatures. The vulnerable path is Linked Data Signatures: the signature is checked over the canonical RDF graph, but JSON-LD can represent the same graph in more than one JSON shape. In affected versions, that gap could let a signed activity be reshaped so that Fedify reads a different ActivityPub object shape than intended.

The fix makes Fedify normalize Linked Data Signature-verified activities against Fedify's local JSON-LD context before interpreting them, and rejects JSON-LD constructs that can preserve the signed RDF graph while changing the ActivityPub object shape consumed by Fedify.

Patched releases are 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3. The GitHub Security Advisory is GHSA-9rfg-v8g9-9367, and the CVE ID is CVE-2026-42462.

Update @fedify/fedify:


npm update @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update @fedify/fedify
bun update @fedify/fedify
deno update @fedify/fedify
After updating, redeploy. If you run other Fedify-based servers, update those too.

Thanks to @Claire for the report and responsible disclosure.

If anything is unclear, ask below.

Reply to @silverpill@mitra.social silverpill@silverpill@mitra.social (2026-05-21 04:49:51) Is the assumption on which FEP-fe34 is based valid?

Of course, it is primarily a philosophical question. Who should be responsible for enforcing boundaries between actors hosted on the same server, the sender or the recipient? In my opinion, the answer is clear: the sender should be responsible.

As far as I know, the majority of existing implementations do enforce boundaries between actors. I am not aware of any implementation that doesn't do that.

Enforcement of boundaries is challenge for generic ActivityPub servers, but it's not insurmountable.

silverpill@silverpill@mitra.social (2026-05-21 04:34:44) I agree out of principle that the security implications exist, but if you follow through with the exploit, it requires a non-compliant server to allow users to publish Update and Delete for other users on the same instance, and even then the exposure is limited to users of that origin only (e.g. your server cannot arbitrarily delete my posts). This is the foundation of the Origin-based security model.

Correct. FEP-fe34 is based on the assumption that originating servers enforce boundaries between actors. This is stated in the section "Assumptions":

The origin-based security model is designed for use in a network where a server is resposible for enforcing security boundaries between the hosted actors. Servers that publish objects without validation are not supported.

In some cases, FEP-fe34 recommends same-actor policy as an additional protection against implementation bugs and against implementations that don't enforce actor boundaries on purpose. Update/Delete authorization is one of those cases (admittedly, the wording is a bit confusing in that paragraph...)

God Emperor of Mastodon@mms@mastodon.bsd.cafe (2026-05-21 04:19:18) #snac doesn't support split domains ;-(

https://mastodon.sapka.pl/

I was *so* close.

fedicat@fedicat@pc.cafe boosted: @golemwire@social.golemwire.com (2026-05-21 02:58:36) I'm really glad #snac uses mode 660 for many of its data files. It makes it really easy for me to add my main user to my server's snac group, and be able to administer as my normal user without su'ing into the snac user.
Lots of people don't seem to think these details through, or they just forget about #unix features. The Snac author ( @grunfink@comam.es ) did it though! Thanks!

Addendum: I also just learned about using the setgid bit on a directory. That was used, too. Cool! https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

fedicat@fedicat@pc.cafe boosted: @FediGarden@social.growyourown.services (2026-05-21 03:58:10) RE: https://cupoftea.social/@Whiskeyomega/116604022593863925

Will runs a really nice public Mastodon server at CupOfTea.social and has put a lot of work into providing people a place on the Fediverse. Unfortunately in real life he has had a neighbour attacking him by throwing a hammer through his window. If you'd like to help him you can do so through his server's ko-fi page which he links in his post below.

silverpill@silverpill@mitra.social boosted: @n0iroh@mastodon.social (2026-05-20 22:43:14) Post-Quantum key exchange in iroh? Thanks to the amazing #rustlang ecosystem and iroh depending on industry-stanard TLS used in a p2p-friendly way this is now possible: https://www.iroh.computer/blog/iroh-post-quantum-handshakes

#pqc #p2p #iroh

Fedi.Garden@FediGarden@social.growyourown.services (2026-05-21 03:58:10) RE: https://cupoftea.social/@Whiskeyomega/116604022593863925

Will runs a really nice public Mastodon server at CupOfTea.social and has put a lot of work into providing people a place on the Fediverse. Unfortunately in real life he has had a neighbour attacking him by throwing a hammer through his window. If you'd like to help him you can do so through his server's ko-fi page which he links in his post below.

Reply to @p@fsebugoutzone.org Tadano@tadano@mt.watamelon.win (2026-05-21 03:37:57) @p @relaystalker @Wiz @mischievoustomato Not a Rust programmer so I just used Claude to get the following:

When Mitra receives a federated post containing remote media (images, videos, etc.), it doesn't serve those remote URLs directly to clients. Instead, it rewrites them to local proxy URLs that go through its own /api/media_proxy/ endpoint. This keeps client IP addresses private and allows Mitra to enforce content-type and size policies.

Configuration

>mitra_config/src/config.rs exposes a media_proxy_enabled flag (default: true). The server checks this at startup in mitra_api/src/server.rs line 55 and only registers the proxy routes when it's enabled.

URL Rewriting (at serialization time)

The rewriting happens inside ClientMediaServer in mitra_api/src/mastodon_api/media_server.rs. Its url_for() method is called whenever an attachment is serialized into an API response.

For local files it returns a direct filesystem-backed URL. For remote links it generates a signed proxy URL:

>The remote URL is hex-encoded.
>An Ed25519 signature is created over the URL bytes using the instance's secret key.
>The signature is hex-encoded.
>The final URL is: {instance_base}/api/media_proxy/{hex_encoded_url}?signature={hex_signature}
>This rewriting is transparent to API consumers. The attachment serialization in mitra_api/src/mastodon_api/media/types.rs line 71 calls media_server.url_for() for every attachment, and status responses in mitra_api/src/mastodon_api/statuses/types.rs line 188 use this path.

The Proxy Endpoint

>Route: GET /api/media_proxy/{url_encoded}?signature={signature}
>Handler: mitra_api/src/mastodon_api/media_proxy/views.rs line 26

When a client fetches a proxy URL, the handler:

>Verifies the Ed25519 signature against the encoded URL bytes using the same instance key. If the signature is invalid, it rejects the request. This prevents clients from crafting arbitrary proxy URLs to fetch anything.
>Calls stream_media() from apx_sdk (apx_sdk/src/fetch.rs li

Reply to @Wiz@tsundere.love pistolero@p@fsebugoutzone.org (2026-05-21 03:18:17) @Wiz @tadano @mischievoustomato @relaystalker Media proxies are a real motherfucker. How does Mitra do them?

Reply to @tadano@mt.watamelon.win Wiz@Wiz@tsundere.love (2026-05-21 03:15:21) @tadano @relaystalker @mischievoustomato I think the commonality is us all being on Pleroma, but, federation is sometimes just gay.

Reply to @Wiz@tsundere.love Tadano@tadano@mt.watamelon.win (2026-05-21 03:13:23) @Wiz @relaystalker It's inconsistent like the PFP of @mischievoustomato doesn't load but yours does, and the other instances mentioned by name are similar in regrards to some stuff just not getting pulled for some reason. Could be my instance doing something wrong when requesting the image, I dunno

Reply to @tadano@mt.watamelon.win Wiz@Wiz@tsundere.love (2026-05-21 03:09:32) @tadano @relaystalker I can't really help with why you can't see our media, but good luck.

fedicat@fedicat@pc.cafe boosted: @fedify@hollo.social (2026-05-21 02:35:44) Fedify security updates: 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3
If you use Fedify, update to a patched release now. CVE-2026-42462 affects Fedify's Linked Data Signature handling. An attacker could use JSON-LD graph-restructuring features to change how a signed activity is interpreted without invalidating its Linked Data Signature.

Fedify verifies incoming ActivityPub activities with several mechanisms, including HTTP Signatures, Object Integrity Proofs, and Linked Data Signatures. The vulnerable path is Linked Data Signatures: the signature is checked over the canonical RDF graph, but JSON-LD can represent the same graph in more than one JSON shape. In affected versions, that gap could let a signed activity be reshaped so that Fedify reads a different ActivityPub object shape than intended.

The fix makes Fedify normalize Linked Data Signature-verified activities against Fedify's local JSON-LD context before interpreting them, and rejects JSON-LD constructs that can preserve the signed RDF graph while changing the ActivityPub object shape consumed by Fedify.

Patched releases are 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3. The GitHub Security Advisory is GHSA-9rfg-v8g9-9367, and the CVE ID is CVE-2026-42462.

Update @fedify/fedify:


npm update @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update @fedify/fedify
bun update @fedify/fedify
deno update @fedify/fedify
After updating, redeploy. If you run other Fedify-based servers, update those too.

Thanks to @Claire for the report and responsible disclosure.

If anything is unclear, ask below.

fedicat@fedicat@pc.cafe boosted: @hollo@hollo.social (2026-05-21 02:39:43) Hollo security updates: 0.7.17, 0.8.6, and 0.9.1
If you run Hollo, update to a patched release now. CVE-2026-42462 affects Fedify's Linked Data Signature handling, and Hollo depends on Fedify for ActivityPub federation.

Fedify verifies incoming ActivityPub activities with several mechanisms, including HTTP Signatures, Object Integrity Proofs, and Linked Data Signatures. The vulnerable path is Linked Data Signatures: the signature is checked over the canonical RDF graph, but JSON-LD can represent the same graph in more than one JSON shape. In affected versions, that gap could let a signed activity be reshaped so that Fedify reads a different ActivityPub object shape than intended—without invalidating the signature.

The fix makes Fedify normalize Linked Data Signature-verified activities against its local JSON-LD context before interpreting them, and rejects JSON-LD constructs that can preserve the signed RDF graph while changing the ActivityPub object shape. For full technical details of the underlying vulnerability, see the Fedify security announcement.

All Hollo versions up to and including 0.7.16, 0.8.5, and 0.9.0 are affected. Patched releases are 0.7.17 for the 0.7.x series, 0.8.6 for the 0.8.x series, and 0.9.1 for the 0.9.x series.

For 0.7.x deployments, update to 0.7.17:


docker pull ghcr.io/fedify-dev/hollo:0.7.17
For 0.8.x deployments, update to 0.8.6:


docker pull ghcr.io/fedify-dev/hollo:0.8.6
For 0.9.x deployments, update to 0.9.1:


docker pull ghcr.io/fedify-dev/hollo:0.9.1
After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.

Thanks to @Claire for the report and responsible disclosure to the Fedify project.

If anything is unclear, ask below.

Ethan Black@golemwire@social.golemwire.com (2026-05-21 02:58:36) I'm really glad #snac uses mode 660 for many of its data files. It makes it really easy for me to add my main user to my server's snac group, and be able to administer as my normal user without su'ing into the snac user.
Lots of people don't seem to think these details through, or they just forget about #unix features. The Snac author ( @grunfink@comam.es ) did it though! Thanks!

Addendum: I also just learned about using the setgid bit on a directory. That was used, too. Cool! https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

Reply to @tadano@mt.watamelon.win silverpill@silverpill@mitra.social (2026-05-21 02:46:26) @tadano

There is a list of breaking changes: https://codeberg.org/silverpill/mitra/src/branch/main/docs/mitra_5_0.md
But most likely none of this affects you

Hollo :hollo:@hollo@hollo.social (2026-05-21 02:39:43) Hollo security updates: 0.7.17, 0.8.6, and 0.9.1
If you run Hollo, update to a patched release now. CVE-2026-42462 affects Fedify's Linked Data Signature handling, and Hollo depends on Fedify for ActivityPub federation.

Fedify verifies incoming ActivityPub activities with several mechanisms, including HTTP Signatures, Object Integrity Proofs, and Linked Data Signatures. The vulnerable path is Linked Data Signatures: the signature is checked over the canonical RDF graph, but JSON-LD can represent the same graph in more than one JSON shape. In affected versions, that gap could let a signed activity be reshaped so that Fedify reads a different ActivityPub object shape than intended—without invalidating the signature.

The fix makes Fedify normalize Linked Data Signature-verified activities against its local JSON-LD context before interpreting them, and rejects JSON-LD constructs that can preserve the signed RDF graph while changing the ActivityPub object shape. For full technical details of the underlying vulnerability, see the Fedify security announcement.

All Hollo versions up to and including 0.7.16, 0.8.5, and 0.9.0 are affected. Patched releases are 0.7.17 for the 0.7.x series, 0.8.6 for the 0.8.x series, and 0.9.1 for the 0.9.x series.

For 0.7.x deployments, update to 0.7.17:


docker pull ghcr.io/fedify-dev/hollo:0.7.17
For 0.8.x deployments, update to 0.8.6:


docker pull ghcr.io/fedify-dev/hollo:0.8.6
For 0.9.x deployments, update to 0.9.1:


docker pull ghcr.io/fedify-dev/hollo:0.9.1
After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.

Thanks to @Claire for the report and responsible disclosure to the Fedify project.

If anything is unclear, ask below.

Reply to @tadano@mt.watamelon.win Tadano@tadano@mt.watamelon.win (2026-05-21 02:36:38) ALSO
>how to pull past posts from profiles quickly so I am not looking at a profile timeline with gaping holes

Fedify: ActivityPub server framework@fedify@hollo.social (2026-05-21 02:35:44) Fedify security updates: 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3
If you use Fedify, update to a patched release now. CVE-2026-42462 affects Fedify's Linked Data Signature handling. An attacker could use JSON-LD graph-restructuring features to change how a signed activity is interpreted without invalidating its Linked Data Signature.

Fedify verifies incoming ActivityPub activities with several mechanisms, including HTTP Signatures, Object Integrity Proofs, and Linked Data Signatures. The vulnerable path is Linked Data Signatures: the signature is checked over the canonical RDF graph, but JSON-LD can represent the same graph in more than one JSON shape. In affected versions, that gap could let a signed activity be reshaped so that Fedify reads a different ActivityPub object shape than intended.

The fix makes Fedify normalize Linked Data Signature-verified activities against Fedify's local JSON-LD context before interpreting them, and rejects JSON-LD constructs that can preserve the signed RDF graph while changing the ActivityPub object shape consumed by Fedify.

Patched releases are 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3. The GitHub Security Advisory is GHSA-9rfg-v8g9-9367, and the CVE ID is CVE-2026-42462.

Update @fedify/fedify:


npm update @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update @fedify/fedify
bun update @fedify/fedify
deno update @fedify/fedify
After updating, redeploy. If you run other Fedify-based servers, update those too.

Thanks to @Claire for the report and responsible disclosure.

If anything is unclear, ask below.

Tadano@tadano@mt.watamelon.win (2026-05-21 02:33:32) Alright now to figure out the following issues:
>why instances like ryona.agency, tsundere.love, annihilation.social aren't loading images (all media is proxied by default i.e. not loaded from a local cache)
>why custom emoji reacts are not working despite cust emotes being usable in posting/being on the server
>if database shenanigans need to be done upgrading from 4.x to 5.3.0
>why federation is slow and how to get older posts in a timely manner (AI log analysis kept mentioning a duplicate key bug, unsure if hallucinatory or me being dumb :cirnoshrug:)
>why @relaystalker is STILL getting stuck on follow requesting with relay accounts
>how to get this instance to communicate with dedicated relays
>how to get tor/tor federation up with this docker setup
>how to federate over I2P
>how to temporarily get schwartzwelt up in a container without all the media so I can migrate all my followers from there to here

All shall be figured out in time as I relearn sysadmining :watamelonogey:
t. Instance running on Rocky Linux for the first time

Repost if you can! God willing this reaches as many Mitra sysadmins as possible because I don't think I can badger silverpill alone without being terribly rude/annoying :watamelonsweat: ---Attachments--- image: https://mt.watamelon.win/media/1e00183e82cb8e3d1434c5114efa6670b1788a50b1341cc603bdf86d3bee7608.png
image: https://mt.watamelon.win/media/35245a3b381a820da851cd964f5ef000f3658165c9906c0d07e4ff3d8f8b5fb3.png

Nova@Chishiki611@enby.life boosted: @misty@digipres.club (2026-05-21 00:40:16) Hometown admins: we’ve released v4.5.10+hometown-1.2.1. This incorporates today’s Mastodon security release which fixes high severity bugs. We recommend that all admins update immediately. https://github.com/hometown-fork/hometown/releases/tag/v4.5.10%2Bhometown-1.2.2

#HometownAdmin

Wafrn - software development and instance info@admin@app.wafrn.net (2026-05-21 01:10:03) Images available now

If you updated last week already, you just use the standard update method



RE: https://app.wafrn.net/fediverse/post/f84a56a2-d43a-4d2a-a461-618fdf0fa53a

SK@sk_@misskey.io (2026-05-21 00:51:55) ​:serina_face_smile:​ ---Attachments--- image: https://media.misskeyusercontent.com/io/9e474d1f-1d9a-43c3-869b-97dc3eaaf357.png?sensitive=true

Coro@Coro@mstdn.maud.io (2026-05-21 00:49:40) green coke、甘くないあっさりめのコカコーラという味でした。

fedicat@fedicat@pc.cafe boosted: @mirlo@musician.social (2026-05-21 00:12:02) We are open source, cooperatively-run, community-led and in the process of joining the social web. We're also working collaboratively with others in the space towards different modes of decentralisation, going against enshittification and one-size-fits-all approaches.

If you'd like to support our work and help allocate more resources towards these things, there are several ways to do so at the link below. Thank you! 💪🐦‍⬛

https://mirlo.space/team/tip

#SupportUs #Fediverse #Support #Coop #Coops

Misty@misty@digipres.club (2026-05-21 00:40:16) Hometown admins: we’ve released v4.5.10+hometown-1.2.1. This incorporates today’s Mastodon security release which fixes high severity bugs. We recommend that all admins update immediately. https://github.com/hometown-fork/hometown/releases/tag/v4.5.10%2Bhometown-1.2.2

#HometownAdmin

Connected Places@fediversereport@mastodon.social (2026-05-21 00:37:12) Various projects on the open social web are working towards private data, whether that's @Mastodon getting funding for adding E2EE, Lemmy's upcoming 1.0 release featuring private communities, or Bluesky's work on expanding atproto with permissioned data.

Bounded communities with private data using open protocols sound quite like @matrix however.

I'm taking a closer look, as this comparison turns out to be quite a lot stranger than expected

https://connectedplaces.online/reports/fr163-decrypting-matrix/

mirlo.space@mirlo@musician.social (2026-05-21 00:12:02) We are open source, cooperatively-run, community-led and in the process of joining the social web. We're also working collaboratively with others in the space towards different modes of decentralisation, going against enshittification and one-size-fits-all approaches.

If you'd like to support our work and help allocate more resources towards these things, there are several ways to do so at the link below. Thank you! 💪🐦‍⬛

https://mirlo.space/team/tip

#SupportUs #Fediverse #Support #Coop #Coops

Nova@Chishiki611@enby.life boosted: @sharkey@sharkey.team (2026-05-20 23:49:46) develop has been updated! happy patching, everyone
Older Notes