検索

返信元:

While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access. When a remote server requests a followers-only post or DM with a valid HTTP Signatures (draft-cavage) from an authorized actor, Misskey still returns 404 instead of the content. It seems Misskey only checks the visibility field (public/home) without verifying the signature at all. #Mastodon takes a different approach—when #authorized_fetch is enabled, it validates the HTTP Signatures and returns the content if the requesting actor has permission. I think it would be beneficial if Misskey could adopt a similar mechanism, since it would better respect the access control semantics that ActivityPub intends. Has anyone else run into this, or are there specific reasons Misskey handles it this way? #fedidev
返信 1 · Renote 0
Fedifyを開発していて気づいたことなんですが、MisskeyのActivityPubオブジェクトへのアクセス処理について少し疑問があります。リモートサーバーから、アクセス権限のあるアクターの有効なHTTP Signaturesを含むリクエストでフォロワー限定投稿やDMにアクセスしようとしても、Misskeyは内容を返さずに404を返すようです。どうやらMisskeyはHTTP Signaturesを検証せず、visibilityフィールド(publicとhome)だけを確認しているようです。 Mastodonの場合、authorized fetchを有効にすると、HTTP Signaturesを検証して、リクエストしているアクターに権限があれば内容を返します。MisskeyもMastodonのような仕組みを採用してくれたら、ActivityPubが意図しているアクセス制御のセマンティクスをより適切に尊重できるんじゃないかと思います。他の方も同じようなことに気づかれたことはありますか?それとも、Misskeyがこのような処理をしている特別な理由があるのでしょうか? #Fedify #Misskey #ActivityPub #Mastodon #authorized_fetch #fedidev

❤ 1

返信 1 · Renote 0
While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access. When a remote server requests a followers-only post or DM with a valid HTTP Signatures (draft-cavage) from an authorized actor, Misskey still returns 404 instead of the content. It seems Misskey only checks the visibility field (public/home) without verifying the signature at all. #Mastodon takes a different approach—when #authorized_fetch is enabled, it validates the HTTP Signatures and returns the content if the requesting actor has permission. I think it would be beneficial if Misskey could adopt a similar mechanism, since it would better respect the access control semantics that ActivityPub intends. Has anyone else run into this, or are there specific reasons Misskey handles it this way? #fedidev
返信 1 · Renote 0
【OSC京都で #Fediverse :fediverse: に関連したセミナーを開催します!】 本日の13:00〜 オープンソースカンファレンス京都 #osckyoto で「分散型SNSユーザー有志」として、 「Fediverseのつくりかた 〜開発者・管理者たちの現場から〜」 と題してセミナー講演を行います! 登壇者として私のほか、 #fedibird :fedibird1: 運営者の @[email protected] さん #Fedify :fedify: #Hollo :hollo: 等の開発者である @[email protected] さん 京都のMastodon地域サーバー #マストどす 管理人の @[email protected] さん をお呼びして開催します。 ActivityPubを中心としたFediverseの今が知れるセミナーです。ぜひご参加ください! 東海道らぐさんのセミナーのオンラインURLでの同時配信もします!! https://tokaidolug.connpass.com/event/361666/ 会場:KRP ルーム2B(2階) 日時:2025年8月3日(日)13:00〜 参加費:無料 セミナー詳細: https://event.ospn.jp/osc2025-kyoto/session/2211664
返信 0 · Renote 1
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @[email protected] project! OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors. We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey. Looking forward to working with these new contributors and seeing what amazing things we can build together! #opensource #mentoring #ActivityPub #fedidev
返信 0 · Renote 1
We're pleased to announce that #Fedify has been included in the Nivenly Fediverse Security Fund program! The @[email protected] Foundation has launched a security bounty fund to support contributors who identify and help fix #security vulnerabilities in popular #fediverse software. Both Fedify and @[email protected] are among the selected projects that meet their responsible security disclosure requirements.

This program will run from April–September 2025, with bounties of $250–$500 USD for high and critical security vulnerabilities.

We're honored to be recognized alongside other established fediverse projects like Mastodon, Misskey, and Lemmy. This further encourages our commitment to maintaining strong security practices.

If you're interested in contributing to Fedify's security, please follow our responsible disclosure process outlined in our SECURITY.md file. Learn more about the program: https://nivenly.org/blog/2025/04/01/nivenly-fediverse-security-fund/
返信 0 · Renote 1

返信元:

#Fedify 프레임워크의 #WebFinger 구현에서 발견된 보안 취약점 CVE-2025-23221을 해결하기 위한 보안 업데이트(1.0.14, 1.1.11, 1.2.11, 1.3.4)를 배포했습니다. 모든 사용자께서는 각자 사용 중인 버전에 해당하는 최신 버전으로 즉시 업데이트하시기를 권장합니다.


취약점 내용


보안 연구자가 Fedify의 lookupWebFinger() 함수에서 다음과 같은 보안 문제점들을 발견했습니다: 무한 리다이렉트 루프를 통한 서비스 거부 공격 가능 내부 네트워크 주소로의 리다이렉트를 통한 SSRF (서버측 요청 위조) 공격 가능 리다이렉트 조작을 통한 의도하지 않은 URL 스킴 접근 가능 수정된 버전 1.3.x 시리즈: 1.3.4로 업데이트 1.2.x 시리즈: 1.2.11로 업데이트 1.1.x 시리즈: 1.1.11로 업데이트 1.0.x 시리즈: 1.0.14로 업데이트



변경 사항


이번 보안 업데이트에는 다음과 같은 수정 사항이 포함되어 있습니다:


무한 리다이렉트 루프를 방지하기 위해 최대 리다이렉트 횟수 제한(5회) 도입

원래 요청과 동일한 스킴(HTTP/HTTPS)으로만 리다이렉트 허용하도록 제한

SSRF 공격 방지를 위해 내부 네트워크 주소로의 리다이렉트 차단



업데이트 방법


다음 명령어로 최신 보안 버전으로 업데이트하실 수 있습니다:


# npm 사용자의 경우
npm update @fedify/fedify

# Deno 사용자의 경우
deno add jsr:@fedify/fedify

이 취약점을 책임감 있게 보고해 주신 보안 연구자께 감사드립니다. 덕분에 신속하게 문제를 해결할 수 있었습니다. 이 취약점에 대한 자세한 내용은 보안 권고문을 참고해 주시기 바랍니다. 문의 사항이나 우려 사항이 있으시다면 GitHub Discussions나 Matrix 채팅방, 또는 Discord 서버를 통해 언제든 연락해 주시기 바랍니다. #보안 #보안패치 #취약점 #SSRF
返信 1 · Renote 1
FedifyのWebFinger実装における脆弱性CVE-2025-23221に対するセキュリティアップデート(1.0.14、1.1.11、1.2.11、1.3.4)をリリースいたしました。すべてのユーザー様におかれましては、お使いのバージョンに応じた最新版への速やかなアップデートを推奨いたします。


脆弱性の詳細


セキュリティ研究者により、FedifyのlookupWebFinger()関数において以下のセキュリティ上の問題が発見されました: 無限リダイレクトループによるサービス拒否攻撃(DoS)の可能性 プライベートネットワークアドレスへのリダイレクトを利用したSSRF(サーバーサイドリクエストフォージェリ)攻撃の可能性 リダイレクト操作による意図しないURLスキームへのアクセスの可能性 修正されたバージョン 1.3.xシリーズ:1.3.4へアップデート 1.2.xシリーズ:1.2.11へアップデート 1.1.xシリーズ:1.1.11へアップデート 1.0.xシリーズ:1.0.14へアップデート



変更内容


本セキュリティアップデートでは、以下の修正が実施されました:


無限リダイレクトループを防ぐため、最大リダイレクト回数(5回)の制限を導入

元のリクエストと同じスキーム(HTTP/HTTPS)のみにリダイレクトを制限

SSRFを防止するため、プライベートネットワークアドレスへのリダイレクトをブロック



アップデート方法


以下のコマンドで最新のセキュアバージョンにアップデートできます:


# npmユーザーの場合
npm update @fedify/fedify

# Denoユーザーの場合
deno add jsr:@fedify/fedify

この脆弱性を責任を持って報告していただいたセキュリティ研究者の方に感謝申し上げます。迅速な対応が可能となりました。 本脆弱性の詳細については、セキュリティ勧告をご参照ください。 ご質問やご懸念がございましたら、GitHub Discussions、Matrixチャットスペース、またはDiscordサーバーまでお気軽にご連絡ください。 #Fedify #WebFinger #セキュリティ #脆弱性 #DoS #SSRF
返信 0 · Renote 1

返信元:

We have released #security updates (1.0.14, 1.1.11, 1.2.11, 1.3.4) to address CVE-2025-23221, a #vulnerability in #Fedify's #WebFinger implementation. We recommend all users update to the latest version of their respective release series immediately.


The Vulnerability


A security researcher identified multiple security issues in Fedify's lookupWebFinger() function that could be exploited to: Perform denial of service attacks through infinite redirect loops Execute server-side request forgery (#SSRF) attacks via redirects to private network addresses Access unintended URL schemes through redirect manipulation Fixed Versions 1.3.x series: Update to 1.3.4 1.2.x series: Update to 1.2.11 1.1.x series: Update to 1.1.11 1.0.x series: Update to 1.0.14



Changes


The security updates implement the following fixes:


Added a maximum redirect limit (5) to prevent infinite redirect loops

Restricted redirects to only follow the same scheme as the original request (HTTP/HTTPS)

Blocked redirects to private network addresses to prevent SSRF attacks



How to Update


To update to the latest secure version:


# For npm users
npm update @fedify/fedify

# For Deno users
deno add jsr:@fedify/fedify

We thank the security researcher who responsibly disclosed this vulnerability, allowing us to address these issues promptly. For more details about this vulnerability, please refer to our security advisory. If you have any questions or concerns, please don't hesitate to reach out through our GitHub Discussions, join our Matrix chat space, or our Discord server.
返信 1 · Renote 1
#Fedify 프레임워크의 #WebFinger 구현에서 발견된 보안 취약점 CVE-2025-23221을 해결하기 위한 보안 업데이트(1.0.14, 1.1.11, 1.2.11, 1.3.4)를 배포했습니다. 모든 사용자께서는 각자 사용 중인 버전에 해당하는 최신 버전으로 즉시 업데이트하시기를 권장합니다.


취약점 내용


보안 연구자가 Fedify의 lookupWebFinger() 함수에서 다음과 같은 보안 문제점들을 발견했습니다: 무한 리다이렉트 루프를 통한 서비스 거부 공격 가능 내부 네트워크 주소로의 리다이렉트를 통한 SSRF (서버측 요청 위조) 공격 가능 리다이렉트 조작을 통한 의도하지 않은 URL 스킴 접근 가능 수정된 버전 1.3.x 시리즈: 1.3.4로 업데이트 1.2.x 시리즈: 1.2.11로 업데이트 1.1.x 시리즈: 1.1.11로 업데이트 1.0.x 시리즈: 1.0.14로 업데이트



변경 사항


이번 보안 업데이트에는 다음과 같은 수정 사항이 포함되어 있습니다:


무한 리다이렉트 루프를 방지하기 위해 최대 리다이렉트 횟수 제한(5회) 도입

원래 요청과 동일한 스킴(HTTP/HTTPS)으로만 리다이렉트 허용하도록 제한

SSRF 공격 방지를 위해 내부 네트워크 주소로의 리다이렉트 차단



업데이트 방법


다음 명령어로 최신 보안 버전으로 업데이트하실 수 있습니다:


# npm 사용자의 경우
npm update @fedify/fedify

# Deno 사용자의 경우
deno add jsr:@fedify/fedify

이 취약점을 책임감 있게 보고해 주신 보안 연구자께 감사드립니다. 덕분에 신속하게 문제를 해결할 수 있었습니다. 이 취약점에 대한 자세한 내용은 보안 권고문을 참고해 주시기 바랍니다. 문의 사항이나 우려 사항이 있으시다면 GitHub Discussions나 Matrix 채팅방, 또는 Discord 서버를 통해 언제든 연락해 주시기 바랍니다. #보안 #보안패치 #취약점 #SSRF
返信 1 · Renote 1
We have released #security updates (1.0.14, 1.1.11, 1.2.11, 1.3.4) to address CVE-2025-23221, a #vulnerability in #Fedify's #WebFinger implementation. We recommend all users update to the latest version of their respective release series immediately.


The Vulnerability


A security researcher identified multiple security issues in Fedify's lookupWebFinger() function that could be exploited to: Perform denial of service attacks through infinite redirect loops Execute server-side request forgery (#SSRF) attacks via redirects to private network addresses Access unintended URL schemes through redirect manipulation Fixed Versions 1.3.x series: Update to 1.3.4 1.2.x series: Update to 1.2.11 1.1.x series: Update to 1.1.11 1.0.x series: Update to 1.0.14



Changes


The security updates implement the following fixes:


Added a maximum redirect limit (5) to prevent infinite redirect loops

Restricted redirects to only follow the same scheme as the original request (HTTP/HTTPS)

Blocked redirects to private network addresses to prevent SSRF attacks



How to Update


To update to the latest secure version:


# For npm users
npm update @fedify/fedify

# For Deno users
deno add jsr:@fedify/fedify

We thank the security researcher who responsibly disclosed this vulnerability, allowing us to address these issues promptly. For more details about this vulnerability, please refer to our security advisory. If you have any questions or concerns, please don't hesitate to reach out through our GitHub Discussions, join our Matrix chat space, or our Discord server.
返信 1 · Renote 1
Hollo 0.3.0 released! #Hollo is a single-user federated microblogging software which is #ActivityPub-enabled and powered by #Fedify. The key changes of this release include: Thanks to @[email protected], Hollo now support local filesystem storage for media files. You can configure DRIVE_DISK=fs and FS_ASSET_PATH to store media files in the local filesystem. For users who've used S3, no further action is required—but, it's recommended to configure DRIVE_DISK=s3 as DRIVE_DISK will be required in the future releases. Added support for Sentry. If you want to see error reports and instrumented traces in Sentry, please configure SENTRY_DSN. Added pagination to the profile page. Minor performance improvements and bug fixes due to upgrading Fedify to 1.3.0. You can upgrade to Hollo 0.3.0 using the following ways: To Railway users: Just redeploy the Hollo service! To Docker users: Switch your Hollo image to ghcr.io/dahlia/hollo:0.3.0 or simply latest! To manual installers: Fetch the stable branch and switch over to it!
返信 0 · Renote 1
Hollo 0.2.0 released! #Hollo is a single-user federated microblogging software which is #ActivityPub-enabled and powered by #Fedify. The key changes of this release include: Thanks to @[email protected], now you can report remote accounts and posts. Added two-factor authentication support. Thanks again to @[email protected], Hollo improved alignment on Mastodon API changes about OAuth and apps. Thanks again to @[email protected], RFC 8414 for OAuth Authorization Server metadata endpoint. It will improve interoperability between Hollo and Mastodon-compatible client apps.





Renamed the Data menu from the administration dashboard to Federation, and: Now posts also can be force-refreshed. Now the number of messages in the task queue is shown. Custom emojis now can be deleted from the administration dashboard. Thanks @[email protected], PORT and ALLOW_PRIVATE_ADDRESS environment variables are introduced. Added a favicon. Dropped support for Redis, which was an optional dependency. You can upgrade to Hollo 0.2.0 using the following ways: To Railway users: Just redeploy the Hollo service! To Docker users: Switch your Hollo image to ghcr.io/dahlia/hollo:0.2.0 or simply latest! To manual installers: Fetch the stable branch and switch over to it!
  • original.png
  • original.png
  • original.png
  • original.png
返信 0 · Renote 1
The version 1.2.0 of #Fedify, an #ActivityPub server framework, released! The key changes include: Added InboxContext.recipient property. It's useful for determining whether it is a shared inbox or a personal inbox, and whose personal inbox is invoked. Added getNodeInfo() function, a NodeInfo client.





Added followedMessage property, which corresponds to _misskey_followedMessage, to Actor type in Activity Vocabulary API. Log messages now can be traced using LogTape's implicit contexts, which means you can filter log messages by requestId (an HTTP request identifier) or messageId (a background task identifier). Now you can choose an AMQP driver (which supports RabbitMQ) for the message queue in the fedify init command. Added the fedify node subcommand, which fetches the given instance's NodeInfo document and visualizes it in neofetch-style. For details, see the full changelog as well! Fedify 1.2.0 is available at JSR and npm. #fedidev
返信 0 · Renote 2
Finally, Hollo 0.1.0 released! #Hollo is a single-user federated microblogging software which is #ActivityPub-enabled and powered by #Fedify. Hollo has the most of features that Mastodon has except for moderation tools, and also include: CommonMark (a.k.a. Markdown) and up to 4,096 characters per post Misskey-style quotes (compatible with Misskey, Akkoma, Fedibird, etc) Misskey-style emoji reactions (both Unicode emojis and custom emojis are supported; compatible with Misskey, Akkoma, kmyblue, etc) Generally much relaxed limitations (more poll options, more attachments, and so on) … and many more! If you're interested in Hollo, please give it a try! There are several ways to install it: using Railway, using Docker (and Docker Compose), or manually. If you're already using Hollo, please upgrade it to v0.1.0: To Railway users: Just redeploy the Hollo service! To Docker users: Switch your Hollo image to ghcr.io/dahlia/hollo:0.1.0 or simply latest! To manual installers: Fetch the stable branch and switch over to it!
返信 0 · Renote 1