#fedify

12 posts · Last used 3d

Boosted by @fedicat@pc.cafe
Fedify security updates: 2.0.30, 2.1.26, 2.2.15, 2.3.10, and 2.4.0 Two vulnerabilities have been fixed: GHSA-97w4-f4rq-mgqm, unbounded alternate-document fetch chains vulnerability and GHSA-39gj-rchc-q5m3, unverified activity routed after dereference verification vulnerability. The patched releases are 2.0.30, 2.1.26, 2.2.15, 2.3.10, and 2.4.0. Both vulnerabilities affect the preceding releases on those lines: 2.0.28 and 2.0.29, 2.1.24 and 2.1.25, 2.2.13 and 2.2.14, 2.3.8 and 2.3.9. If you still use Fedify 1.x, change your dependency to patched 2.x release because package-manager update commands do not cross the declared major-version range. Unbounded alternate-document fetch chains (GHSA-97w4-f4rq-mgqm, high, CVSS 7.5) GHSA-97w4-f4rq-mgqm affects Fedify's document loaders when fetching remote keys and ActivityPub documents. Fedify follows alternate-document links supplied through HTTP Link headers and HTML, but following an alternate document reset the redirect counter and visited-URL history. An attacker could therefore make two URLs refer to each other as alternate documents and cause Fedify to fetch them indefinitely. Following an alternate link also dropped the caller's cancellation signal, so aborting the original operation did not stop the fetch chain. An unauthenticated inbox request could exploit this by referencing an attacker-controlled signing-key URL. Resolving the key could then enter an unbounded alternate-document chain, continuously issuing HTTP requests and DNS lookups and eventually exhausting server resources. Both getDocumentLoader() and getAuthenticatedDocumentLoader() were affected, including their use in @fedify/vocab-runtime and @fedify/fedify. The fix makes alternate-document links and ordinary HTTP redirects share the same 20-hop limit and visited-URL history. It also preserves the caller's cancellation signal throughout the entire fetch chain. This closes a gap left by the earlier redirect-loop fix for CVE-2026-34148. Unverified activity routed after dereference verification (GHSA-39gj-rchc-q5m3, medium, CVSS 6.5) GHSA-39gj-rchc-q5m3 has been present since Context.routeActivity() was introduced in Fedify 1.3.0. Context.routeActivity() verifies an activity before passing it to inbox listeners. When an activity has no verifiable Object Integrity Proof, Fedify dereferences its id and verifies the fetched copy. However, only the Activity object was replaced with the verified copy; the original, unverified JSON-LD document supplied by the caller was retained. With an inbox queue configured, that unverified document was enqueued and later delivered to inbox listeners without being verified again. An attacker who knew the ID of any dereferenceable activity could therefore submit a document with the same ID but an actor, object, and addressing of their choice, causing the application to process attacker-controlled data as authenticated. Without a queue, listeners received the verified Activity object, but their InboxContext still contained the unverified document, which InboxContext.forwardActivity() could forward to other servers. Applications that never call Context.routeActivity() are not affected. Activities successfully authenticated using an Object Integrity Proof are also unaffected, as is the HTTP inbox, which does not use this routing path. The fix replaces both the Activity object and its JSON-LD document with the verified copy when Context.routeActivity() falls back to dereferencing. Inbox queues, InboxContext, and forwarding therefore all operate on the same document that was actually authenticated. Updating Update @fedify/fedify: npm update @fedify/fedify yarn upgrade @fedify/fedify pnpm update @fedify/fedify bun update @fedify/fedify deno update @fedify/fedify Check if your resolved dependency versions are at least 2.0.30, 2.1.26, 2.2.15, 2.3.10, or 2.4.0 on the corresponding release line. Please redeploy every Fedify-based servers, after updating. The full Github Security Advisories are GHSA-97w4-f4rq-mgqmand GHSA-39gj-rchc-q5m3. Thanks to @adelzaitri for reporting unverified activity is routed after dereference verification issue. Ask below if anything is unclear.
0
0
1
0
Boosted by @fedicat@pc.cafe
Fedify 2.4.0 is out. The main addition is support for FEP-ef61 portable objects. A Fedify server can now host actors whose identity is a DID instead of a domain, serve their signed objects through /.well-known/apgateway/, and verify the portable objects of other servers. I tested it against tootik and Mitra, and wrote up where Fedify's profile differs from the FEP and what it leaves out. The release also adds application-defined background tasks, the ActivityPub Media Upload extension, per-request inbox reports, 410 Gone for deleted objects, and four new packages (AdonisJS, Netlify, PGlite, and interaction controls). Some defaults changed, so please read the upgrading section before you update, especially if you federate with software that uses FEP-ef61 compatible identifiers. Release notes: https://hackers.pub/@fedify/2026/fedify-2-4 Thanks to everyone who contributed to this cycle, and to @silverpill@mitra.social for patient answers about the FEP. #Fedify #ActivityPub #fedidev #FEP_ef61
2
0
6
0
<p><a href="http://httpsig.org/" rel="nofollow ugc">httpsig.org</a> is a site with one sole purpose, to advocate for the adoption of <a href="https://www.rfc-editor.org/rfc/rfc9421.html" rel="nofollow ugc">RFC 9421 HTTP Signatures</a>. It has a "Libraries" tab that does exactly what it advertises, it lists a bunch of libraries for you to use so you don't have to roll your own.</p> <p>If you want to integrate AP today, but you don't want to roll your own everything, where do you go? Who do you ask?</p> <p>All I know is:</p> <ul> <li><a href="https://fedify.dev/" rel="nofollow ugc">Fedify</a> → Typescript (thanks <a href="https://hollo.social/@hongminhee">@<bdi>hongminhee@hollo.social</bdi></a>!)</li> <li><a href="https://github.com/go-ap/fedbox" rel="nofollow ugc">FedBOX</a> → Go (thanks <a href="https://metalhead.club/@mariusor">@<bdi>mariusor@metalhead.club</bdi></a>!)[...]</li></ul>
0
12
0
0
Boosted by @fedicat@pc.cafe
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet@social.nlnet.nl funding and now has its own account here: @drfed@hackers.pub. #DrFed #fedidev #fediverse #NLnet RE: https://hackers.pub/@drfed/019ed3c9-7e8c-782f-a512-5fbc75a4610b
Quoting
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet@social.nlnet.nl, through the NGI0 Commons Fund. #DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed. We're the team behind @fedify@hollo.social: @2chanhaeng@hackers.pub, @gaebalgom@hackers.pub, @hongminhee@hollo.social, and @z9mb1@hackers.pub. We'll post updates when there's something to try. #fedidev #fediverse
Open quoted post
9
1
10
0
Boosted by @fedicat@pc.cafe
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet@social.nlnet.nl, through the NGI0 Commons Fund. #DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed. We're the team behind @fedify@hollo.social: @2chanhaeng@hackers.pub, @gaebalgom@hackers.pub, @hongminhee@hollo.social, and @z9mb1@hackers.pub. We'll post updates when there's something to try. #fedidev #fediverse
0
0
1
1
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed@mastodon.social, with @fedify@hollo.social and @nuxt@m.webtoo.ls, here it is: https://pr-731-0.fedify.pages.dev/tutorial/content-sharing If you'd like to give feedback after reading it, please leave a comment on the following PR: https://github.com/fedify-dev/fedify/pull/731 #Fedify #fedidev #ActivityPub #Nuxt #Pixelfed
32
3
54
1
Replying to
Honestly, I don't really care what strategy other #ActivityPub implementations follow to comply with the spec. (I solved it in #Fedify by just using a proper JSON-LD processor.) It's just a bit annoying that I always send valid JSON-LD documents, but whenever I encounter an interoperability bug where the other side can't process them, I'm the one who has to send them a patch to fix it. 😩
11
9
8
0
You've seen all posts