Federated Timeline

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

Federated Timeline


:minahoshi_omotedero:¡るみ㌨Да!:minahoshi_omotedero:@rumisan@eth.rumiserver.com (2026-05-21 06:15:44)
大阪に着きました
---Attachments---
image: https://data.rumiserver.com/rumimisskey/file/original/webpublic/webpublic-4805044d-6e4f-4c23-b310-b21d012cc55e.webp


fedicat@fedicat@pc.cafe boosted:
@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/


fedicat@fedicat@pc.cafe boosted:
@silverpill@mitra.social (2026-05-21 05:57:34)
- https://github.com/mastodon/mastodon/releases/tag/v4.5.10
- https://hollo.social/@fedify/019e4675-05bc-7725-bcf4-aa51d6af70a0
- https://shrimp.meow.company/notes/amhmis327j0wve4w
- https://shrimp.meow.company/notes/amhmiqtsbwgmt158
- https://activitypub.software/TransFem-org/Sharkey/-/releases/2025.4.7
- https://hubzilla.org/item/53f3509f-d63d-494c-a431-ac84df9c6a57
- https://w.on-t.work/activitypub/may-2026-vulnerability

>Fix Linked-Data Signature bypass through JSON-LD graph restructuring features

JSON-LD adds nothing to Fediverse except bugs and security vulnerabilities.

Of course, there is an alternative to Linked Data signatures that doesn't require Linked Data, much simpler and more secure:

FEP-8b32: Object Integrity Proofs

#activityPub #fedidev


warabi餅@w4rabimochi@misskey.io (2026-05-21 06:01:06)
:ohayoo:


silverpill@silverpill@mitra.social (2026-05-21 05:57:34)
- https://github.com/mastodon/mastodon/releases/tag/v4.5.10
- https://hollo.social/@fedify/019e4675-05bc-7725-bcf4-aa51d6af70a0
- https://shrimp.meow.company/notes/amhmis327j0wve4w
- https://shrimp.meow.company/notes/amhmiqtsbwgmt158
- https://activitypub.software/TransFem-org/Sharkey/-/releases/2025.4.7
- https://hubzilla.org/item/53f3509f-d63d-494c-a431-ac84df9c6a57
- https://w.on-t.work/activitypub/may-2026-vulnerability

>Fix Linked-Data Signature bypass through JSON-LD graph restructuring features

JSON-LD adds nothing to Fediverse except bugs and security vulnerabilities.

Of course, there is an alternative to Linked Data signatures that doesn't require Linked Data, much simpler and more secure:

FEP-8b32: Object Integrity Proofs

#activityPub #fedidev


Reply to @silverpill@mitra.social
julian@julian@activitypub.space (2026-05-21 05:36:09)
@silverpill@mitra.social said:


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...)



Does this mean NodeBB is wrong is allowing different actors on the same origin to publish Updates and Deletes? I do not know of a way to reconcile this with the ability to have moderators carry out their actions.


Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-05-21 05:32:48)
@phnt @tadano @mischievoustomato Yeah I also figured out automated publishing to the package registry: https://codeberg.org/silverpill/minimitra/src/branch/main/.woodpecker/build.yaml#L20

Haven't tried to publish deb yet, but according to the documentation deb is supported.


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-05-21 05:24:49)
@silverpill @tadano @mischievoustomato You can also publish the deb package to the Gitea Debian package registry, if that wasn't removed on Codeberg. So users can add the registry as a repository and get updates via system updates as well.


fedicat@fedicat@pc.cafe (2026-05-21 05:14:22)
trying out a policy of hiding link preview images that have no alt text
---Attachments---
image: https://cdn.masto.host/pccafe/media_attachments/files/116/608/733/038/995/673/original/70a9119146bdb770.jpeg
image: https://cdn.masto.host/pccafe/media_attachments/files/116/608/733/117/172/327/original/a5a972c9140a2826.jpeg


fedicat@fedicat@pc.cafe boosted:
@reiver@mastodon.social (2026-05-21 04:55:59)
Here is my work-in-progress FEP for using JSON Resume with ActivityPub:

FEP-6158: ActivityPub 'Resume' Object: JSON Resume expressed as JSON-LD

https://codeberg.org/reiver/fep/src/branch/fep-6158/fep/6158/fep-6158.md

I prefer to write for clarity, so it still needs work.

#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONResume #fep6158 #fep_6158


silverpill@silverpill@mitra.social (2026-05-21 05:04:46)
@0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd This is one of the reasons I don't build on Nostr. It's full of delusional bitcoin cultists


Reply to @mischievoustomato@tsundere.love
silverpill@silverpill@mitra.social (2026-05-21 05:03:21)
@mischievoustomato @tadano I figured out how to do CI, so now we can build packages automatically on Codeberg


Reply to @reiver@mastodon.social
@reiver ⊼ (Charles) :batman:@reiver@mastodon.social (2026-05-21 04:55:59)
Here is my work-in-progress FEP for using JSON Resume with ActivityPub:

FEP-6158: ActivityPub 'Resume' Object: JSON Resume expressed as JSON-LD

https://codeberg.org/reiver/fep/src/branch/fep-6158/fep/6158/fep-6158.md

I prefer to write for clarity, so it still needs work.

#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONResume #fep6158 #fep_6158

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.

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:

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.

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

Older Notes