@hongminhee@hollo.social · Reply to Daniel Supernault
@dansup Great job! I tested it with my Hollo instance, and it already works well! 👍
洪 民憙 (Hong Minhee) 
@hongminhee@hollo.social
1,120 following1,656 followers
An intersectionalist, feminist, and socialist living in Seoul (UTC+09:00). @tokolovesme's spouse. Who's behind @fedify, @hollo, and @botkit. Write some free software in #TypeScript, #Haskell, #Rust, & #Python. They/them.
서울에 사는 交叉女性主義者이자 社會主義者. 金剛兔(@tokolovesme)의 配偶者. @fedify, @hollo, @botkit 메인테이너. #TypeScript, #Haskell, #Rust, #Python 等으로 自由 소프트웨어 만듦.
- Website
- Hackers' Pub
@dansup@mastodon.social
https://columnly.social is a Mastodon/Pixelfed column based multi-account client I'm building for myself.
- It's hosted in Canada
- Without Cloudflare enabled
- There is no 3rd party servers, Columnly speaks directly with your server
- It will be licensed under AGPL-3.0 and open sourced later this year.
columnly.social
Columnly
The fediverse, in columns. A multi-column client for Mastodon and Pixelfed.
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:
#Gukhanmun 0.3.0をリリースしました。漢字の異体字認識、後ろに続く助詞による読みの選択、句読点プロファイル、外来語表記用例の同梱が入っています。
沖縄県（新字体）は、辞書にある沖繩縣（康熙字典体）と照合して오키나와현と読みます。--hanja-variant-setは漢字を新字体や康熙字典体で出力し直します。一切は既定で일절ですが、一切를のように後ろに付く助詞によって일체を選びます。--punctuation modernは하나、둘。を하나, 둘.に変えます。国立国語院の『外来語表記用例』を辞書としてko-krプリセットに同梱したので、香港が홍콩と読まれるようになりました。
v0.2.xからアップグレードする場合は、ko-krプリセットの出力が変わり、同梱辞書ファイルが形式v2になるので、バインディングとデータパッケージを一緒に上げてください。
github.com
Gukhanmun 0.3.0: Han character variants, particle-based reading selection, punctuation profiles, and loanword spellings · dahlia/gukhanmun · Discussion #32
Gukhanmun is a library and CLI tool for converting Korean text written in mixed hanja/hangul script into consistently annotated output. Academic texts, historical documents, and legal materials rou...
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:
#Gukhanmun 0.3.0 is out with Han character variants, reading selection from following particles, punctuation profiles, and a bundled loanword dictionary.
沖縄県 (shinjitai) now finds 沖繩縣 (Kanxi form) in the dictionary and reads 오키나와현, while --hanja-variant-set re-emits hanja in shinjitai or Kanxi form. 一切 defaults to 일절, but a following particle such as 一切를 selects 일체, and --punctuation modern turns 하나、둘。 into 하나, 둘.. The National Institute of Korean Language's loanword spelling examples are bundled into the ko-kr preset as well, which is why 香港 now reads 홍콩.
Upgrading from v0.2.x changes ko-kr output and moves the bundled dictionaries to format v2, so upgrade the bindings and data packages together.
https://github.com/dahlia/gukhanmun/discussions/32
#hanja #hangul #korean #國漢文 #國漢文混用 #國漢文混用體 #국한문 #국한문혼용 #국한문혼용체
github.com
Gukhanmun 0.3.0: Han character variants, particle-based reading selection, punctuation profiles, and loanword spellings · dahlia/gukhanmun · Discussion #32
Gukhanmun is a library and CLI tool for converting Korean text written in mixed hanja/hangul script into consistently annotated output. Academic texts, historical documents, and legal materials rou...
@hongminhee@hollo.social
#Gukhanmun 0.3.0이 나왔습니다. #漢字 異體字 認識, 助詞를 利用한 讀音 選擇, 句讀 符號 프로파일, 內藏 外來語 表記 用例가 들어갔습니다.
沖縄県(新字體)은 辭典에서 沖繩縣(康熙字典體)을 찾아 오키나와현으로 읽고, --hanja-variant-set은 漢字를 新字體나 康熙字典體로 다시 出力합니다. 一切은 일절이 基本이지만 一切를과 같이 뒤에 붙는 助詞에 따라 일체를 고르며, --punctuation modern은 하나、둘。을 하나, 둘.로 바꿉니다. 또한, 國立國語院 《外來語 表記 用例》를 辭典으로 묶어 ko-kr 프리셋에 넣었습니다. 德分에 香港이 홍콩으로 읽힙니다.
v0.2.x에서 올릴 때는 ko-kr 프리셋의 出力이 달라지고 內藏 辭典 파일이 形式 v2로 바뀌므로, 바인딩과 데이터 패키지를 함께 올리세요.
github.com
Gukhanmun 0.3.0: Han character variants, particle-based reading selection, punctuation profiles, and loanword spellings · dahlia/gukhanmun · Discussion #32
Gukhanmun is a library and CLI tool for converting Korean text written in mixed hanja/hangul script into consistently annotated output. Academic texts, historical documents, and legal materials rou...
Seoul 1988 Olympic logo :)
ALT text
Seoul 1988 Olympic logo
@hongminhee@hollo.social
빵은 그다지 좋아하지 않지만 햄버거는 좋아한다. 그래서 빵 代身 밥이 들어간 라이스버거를 좋아한다. 모스버거에서 파는 モスライスバーガー燒肉를 가장 좋아하는데, 아쉽게도 韓國에서는 안 팔아서 日本에 갈 때만 가끔 사 먹는다. 韓國에서는 그 代身 롯데리아에서 파는 全州 비빔라이스 버거를 즐겨 먹는다. 오늘도 이걸 먹었다. 이 메뉴는 反對로 또 日本 ゼッテリア(日本 롯데리아는 2023年에 すき家 等의 母會社인 ゼンショーホールディングス에 賣却되어, 商號가 바뀌었다)에서는 안 판다.
lotteeatz.com
LOTTE EATZ
전주 비빔라이스 버거
@moreal@hackers.pub
@moreal@hackers.pub
https://github.com/antfu/furifont 보고 한글도 되나 했는데 잘 되네
ALT text
어두운 배경에 흰색 글씨로 "이도건, 제 이름은 李濤件 입니다. 음낙 '音樂'과 '音樂'"이라는 문구가 적혀 있습니다. 글자 위에는 작게 한글 독음이 병기되어 있습니다.
ALT text
검은색 배경에 흰색 글씨로 "제 이름은 이도건 입니다."와 그 아래에 ""음 낙"과 "음악""이라는 문구가 적혀 있습니다.
@hongminhee@hollo.social · Reply to Tim Apple
@timapple Thanks! Yeah, it's actually a very specific problem for people who still write in mixed-script Korean today like me (which is very rare). 😂
@hongminhee@hollo.social · Reply to Daniel Supernault
@dansup Thanks!! 🥰
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:
I'm happy and honored that Gukhanmun has been selected as one of the five recipients of FOSS for All Microgrants 2026! Gukhanmun is my Rust/JavaScript library and CLI tool for converting mixed-script Korean text, which combines hangul and hanja, into hangul-only text.
FOSS for All Microgrants is a new program launching this year that collects donations to support open source projects and communities. It also explores fiscal sponsorship by paying expenses on recipients’ behalf, alongside direct grants.
Thank you to @fossforall, the reviewers, and everyone who donated to the program. I'm grateful for your support for Gukhanmun and its continued development.
@hongminhee@hollo.social
제가 開發하는 Gukhanmun이 FOSS for All Microgrants 2026의 受惠 組織으로 選定되었습니다! Gukhanmun은 國漢文混用體로 쓰인 韓國語 文書를 한글 專用으로 變換하는 Rust/JavaScript 라이브러리이자 CLI 道具입니다.
올해 처음 始作하는 이 事業의 支援을 받게 되어 무척 기쁘고 榮光스럽습니다. @fossforall 및 審査委員 여러분, 그리고 寄附로 함께해 주신 모든 분께 感謝드립니다. Gukhanmun의 開發을 繼續해 나가는 데 큰 힘이 되겠습니다!
https://forum.fossforall.org/t/foss-for-all-microgrants-2026/162
forum.fossforall.org
FOSS for All Microgrants 2026: 수혜조직 선정 완료 공고
올해 처음 진행중인 우리 단체의 기부금 모집 및 분배 사업인 FOSS for All Microgrants 사업에 많은 관심을 가져 주셔서 감사합니다. 오늘 Microgrants 팀 에서는, 심사위원 분들과 최종 수혜조직 선정을 위한 회의를 진행 하였습니다. 그 결과로, 지원을 받은 13곳의 프로젝트 및 커뮤니티 중에서 최종적으로 5곳의 수혜조직을 선정 하였습니다. 선정된 조직은 아래와 같으며, 금주 안으로 후속 절차를 이메일로 안내 드릴 예정입니다. 선정된 수혜조직 구성원 분들 모두 축하 드리며, 큰 기부금은 아니지만, 프로젝트와 커뮤니티의 성장에 조금이나마 도움이 되기를 바랍니다! llvm-z80 llvm-z80 은 llvm 의 다운스트림 프로젝트로, 게임보이 등 단말기에 사용되는 8비트 마이크로프로세서인 Z80 프로세서를 위한 llvm 컴파일러 백엔드 프로젝트 입니다. 장기적으로 z80 백엔드 지원을 llvm 에 업스트림 하여 기여하는 목표를 가지고 있습니다. Spine ...
@lobsters@mastodon.social
Beginning of the Ende (a community Deno fork) via @hongminhee https://lobste.rs/s/8ejwsp #javascript
https://blog.webb.page/WM-105
blog.webb.page
Beginning of the Ende
The trend of VC-backed tooling ending in abandonment rears its ugly head again. But hey, people gotta eat, right? The community will pick up the slack and steward the projects, right?
@hongminhee@hollo.social
A community fork of Deno.
ende.sh
Ende
@netopwibby@social.coop
NEW_MEMO: Beginning of the Ende https://blog.webb.page/WM-105
Deno’s going bye-bye in a year and it’s the foundation of my APIs and my latest project…so I’m forking it and making drastic changes (like ripping out Node compatibility, good riddance).
blog.webb.page
Beginning of the Ende
The trend of VC-backed tooling ending in abandonment rears its ugly head again. But hey, people gotta eat, right? The community will pick up the slack and steward the projects, right?
@netopwibby@social.coop
NEW_MEMO: Beginning of the Ende https://blog.webb.page/WM-105
Deno’s going bye-bye in a year and it’s the foundation of my APIs and my latest project…so I’m forking it and making drastic changes (like ripping out Node compatibility, good riddance).
blog.webb.page
Beginning of the Ende
The trend of VC-backed tooling ending in abandonment rears its ugly head again. But hey, people gotta eat, right? The community will pick up the slack and steward the projects, right?
@dansup@mastodon.social
https://fedidb.com is essentially now a wiki, and we store no passwords or emails, its all powered by oauth and your existing fediverse accounts!
I need more trusted people to help moderate, so I will reach out to a few people.
ALT text
FediDB mod log
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:
Holloの複数のセキュリティ脆弱性に対応するセキュリティアップデートがリリースされました。お早めにアップデートしてください！
https://hollo.social/@hollo/01a1493c-36f9-7992-a6e9-5d10cd3201b7
hollo.social
### Hollo security updates: 0.…
### Hollo security updates: 0.8.16 and 0.9.24 If you run Hollo, update to [0.8.16] or [0.9.24] now. These releases fix [GHSA-v2qh-w789-xxj6], a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use. For [GHSA-v2qh-w789-xxj6], an authenticated client with the `write:statuses` scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check. For [GHSA-97w4-f4rq-mgqm], Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were [0.8.13] and [0.9.20], incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected. For [GHSA-4qhx-hhwf-8685], Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache. For [GHSA-8863-8468-7hq7], Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually. Both of these authentication fixes first reached Hollo in [0.8.15] and [0.9.23], incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too. The other Fedify advisory, [GHSA-39gj-rchc-q5m3], concerns `Context.routeActivity()`: after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in [0.8.14] and [0.9.21]. For full technical details on the upstream issues, see the linked advisories and the [October 4 Fedify announcement] and [October 16 Fedify announcement]. The supported Hollo release lines are 0.8.x and 0.9.x under the [Hollo security policy]. Operators on 0.7.x or earlier should move to a supported line. For 0.8.x deployments, update to [0.8.16]: ~~~~ bash docker pull ghcr.io/fedify-dev/hollo:0.8.16 ~~~~ For 0.9.x deployments, update to [0.9.24]: ~~~~ bash docker pull ghcr.io/fedify-dev/hollo:0.9.24 ~~~~ After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run `docker compose up -d`. For source deployments, check out the corresponding release tag, run `pnpm install --frozen-lockfile` with that tag's pinned pnpm version, run `pnpm run build`, and restart the server. If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the [0.9.20 index preparation instructions] before starting the new version to avoid blocking writes during its automatic migration. Thanks to Yami Odymel (@yamiodymel@misskey.io) for reporting the status deletion issue to Hollo, to Adel Zaitri ([@adelzaitri]) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng@hackers.pub) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance. If anything is unclear, ask below. [0.8.16]: https://github.com/fedify-dev/hollo/releases/tag/0.8.16 [0.9.24]: https://github.com/fedify-dev/hollo/releases/tag/0.9.24 [GHSA-v2qh-w789-xxj6]: https://github.com/fedify-dev/hollo/security/advisories/GHSA-v2qh-w789-xxj6 [GHSA-97w4-f4rq-mgqm]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-97w4-f4rq-mgqm [0.8.13]: https://github.com/fedify-dev/hollo/releases/tag/0.8.13 [0.9.20]: https://github.com/fedify-dev/hollo/releases/tag/0.9.20 [GHSA-4qhx-hhwf-8685]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-4qhx-hhwf-8685 [GHSA-8863-8468-7hq7]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-8863-8468-7hq7 [0.8.15]: https://github.com/fedify-dev/hollo/releases/tag/0.8.15 [0.9.23]: https://github.com/fedify-dev/hollo/releases/tag/0.9.23 [GHSA-39gj-rchc-q5m3]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-39gj-rchc-q5m3 [0.8.14]: https://github.com/fedify-dev/hollo/releases/tag/0.8.14 [0.9.21]: https://github.com/fedify-dev/hollo/releases/tag/0.9.21 [October 4 Fedify announcement]: https://github.com/fedify-dev/fedify/discussions/1221 [October 16 Fedify announcement]: https://github.com/fedify-dev/fedify/discussions/1301 [Hollo security policy]: https://github.com/fedify-dev/hollo/blob/main/SECURITY.md [0.9.20 index preparation instructions]: https://github.com/fedify-dev/hollo/blob/0.9.24/CHANGES.md#version-0920 [@adelzaitri]: https://github.com/adelzaitri
@hollo@hollo.social
Hollo security updates: 0.8.16 and 0.9.24
If you run Hollo, update to 0.8.16 or 0.9.24 now. These releases fix GHSA-v2qh-w789-xxj6, a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use.
For GHSA-v2qh-w789-xxj6, an authenticated client with the write:statuses scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check.
For GHSA-97w4-f4rq-mgqm, Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were 0.8.13 and 0.9.20, incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected.
For GHSA-4qhx-hhwf-8685, Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache.
For GHSA-8863-8468-7hq7, Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually.
Both of these authentication fixes first reached Hollo in 0.8.15 and 0.9.23, incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too.
The other Fedify advisory, GHSA-39gj-rchc-q5m3, concerns Context.routeActivity(): after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in 0.8.14 and 0.9.21. For full technical details on the upstream issues, see the linked advisories and the October 4 Fedify announcement and October 16 Fedify announcement.
The supported Hollo release lines are 0.8.x and 0.9.x under the Hollo security policy. Operators on 0.7.x or earlier should move to a supported line.
For 0.8.x deployments, update to 0.8.16:
docker pull ghcr.io/fedify-dev/hollo:0.8.16For 0.9.x deployments, update to 0.9.24:
docker pull ghcr.io/fedify-dev/hollo:0.9.24After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile with that tag's pinned pnpm version, run pnpm run build, and restart the server.
If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during its automatic migration.
Thanks to Yami Odymel (@yamiodymel) for reporting the status deletion issue to Hollo, to Adel Zaitri (@adelzaitri) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance.
If anything is unclear, ask below.
github.com
adelzaitri - Overview
Security researcher & engineer | CISSP | Incoming PhD student in Offensive Cyber Engineering - adelzaitri
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:
多數의 Hollo 保安 脆弱點에 對한 保安 업데이트가 릴리스되었으니, 早速히 업데이트 바랍니다!
https://hollo.social/@hollo/01a1493c-36f9-7992-a6e9-5d10cd3201b7
hollo.social
### Hollo security updates: 0.…
### Hollo security updates: 0.8.16 and 0.9.24 If you run Hollo, update to [0.8.16] or [0.9.24] now. These releases fix [GHSA-v2qh-w789-xxj6], a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use. For [GHSA-v2qh-w789-xxj6], an authenticated client with the `write:statuses` scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check. For [GHSA-97w4-f4rq-mgqm], Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were [0.8.13] and [0.9.20], incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected. For [GHSA-4qhx-hhwf-8685], Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache. For [GHSA-8863-8468-7hq7], Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually. Both of these authentication fixes first reached Hollo in [0.8.15] and [0.9.23], incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too. The other Fedify advisory, [GHSA-39gj-rchc-q5m3], concerns `Context.routeActivity()`: after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in [0.8.14] and [0.9.21]. For full technical details on the upstream issues, see the linked advisories and the [October 4 Fedify announcement] and [October 16 Fedify announcement]. The supported Hollo release lines are 0.8.x and 0.9.x under the [Hollo security policy]. Operators on 0.7.x or earlier should move to a supported line. For 0.8.x deployments, update to [0.8.16]: ~~~~ bash docker pull ghcr.io/fedify-dev/hollo:0.8.16 ~~~~ For 0.9.x deployments, update to [0.9.24]: ~~~~ bash docker pull ghcr.io/fedify-dev/hollo:0.9.24 ~~~~ After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run `docker compose up -d`. For source deployments, check out the corresponding release tag, run `pnpm install --frozen-lockfile` with that tag's pinned pnpm version, run `pnpm run build`, and restart the server. If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the [0.9.20 index preparation instructions] before starting the new version to avoid blocking writes during its automatic migration. Thanks to Yami Odymel (@yamiodymel@misskey.io) for reporting the status deletion issue to Hollo, to Adel Zaitri ([@adelzaitri]) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng@hackers.pub) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance. If anything is unclear, ask below. [0.8.16]: https://github.com/fedify-dev/hollo/releases/tag/0.8.16 [0.9.24]: https://github.com/fedify-dev/hollo/releases/tag/0.9.24 [GHSA-v2qh-w789-xxj6]: https://github.com/fedify-dev/hollo/security/advisories/GHSA-v2qh-w789-xxj6 [GHSA-97w4-f4rq-mgqm]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-97w4-f4rq-mgqm [0.8.13]: https://github.com/fedify-dev/hollo/releases/tag/0.8.13 [0.9.20]: https://github.com/fedify-dev/hollo/releases/tag/0.9.20 [GHSA-4qhx-hhwf-8685]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-4qhx-hhwf-8685 [GHSA-8863-8468-7hq7]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-8863-8468-7hq7 [0.8.15]: https://github.com/fedify-dev/hollo/releases/tag/0.8.15 [0.9.23]: https://github.com/fedify-dev/hollo/releases/tag/0.9.23 [GHSA-39gj-rchc-q5m3]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-39gj-rchc-q5m3 [0.8.14]: https://github.com/fedify-dev/hollo/releases/tag/0.8.14 [0.9.21]: https://github.com/fedify-dev/hollo/releases/tag/0.9.21 [October 4 Fedify announcement]: https://github.com/fedify-dev/fedify/discussions/1221 [October 16 Fedify announcement]: https://github.com/fedify-dev/fedify/discussions/1301 [Hollo security policy]: https://github.com/fedify-dev/hollo/blob/main/SECURITY.md [0.9.20 index preparation instructions]: https://github.com/fedify-dev/hollo/blob/0.9.24/CHANGES.md#version-0920 [@adelzaitri]: https://github.com/adelzaitri
@hollo@hollo.social
Hollo security updates: 0.8.16 and 0.9.24
If you run Hollo, update to 0.8.16 or 0.9.24 now. These releases fix GHSA-v2qh-w789-xxj6, a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use.
For GHSA-v2qh-w789-xxj6, an authenticated client with the write:statuses scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check.
For GHSA-97w4-f4rq-mgqm, Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were 0.8.13 and 0.9.20, incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected.
For GHSA-4qhx-hhwf-8685, Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache.
For GHSA-8863-8468-7hq7, Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually.
Both of these authentication fixes first reached Hollo in 0.8.15 and 0.9.23, incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too.
The other Fedify advisory, GHSA-39gj-rchc-q5m3, concerns Context.routeActivity(): after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in 0.8.14 and 0.9.21. For full technical details on the upstream issues, see the linked advisories and the October 4 Fedify announcement and October 16 Fedify announcement.
The supported Hollo release lines are 0.8.x and 0.9.x under the Hollo security policy. Operators on 0.7.x or earlier should move to a supported line.
For 0.8.x deployments, update to 0.8.16:
docker pull ghcr.io/fedify-dev/hollo:0.8.16For 0.9.x deployments, update to 0.9.24:
docker pull ghcr.io/fedify-dev/hollo:0.9.24After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile with that tag's pinned pnpm version, run pnpm run build, and restart the server.
If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during its automatic migration.
Thanks to Yami Odymel (@yamiodymel) for reporting the status deletion issue to Hollo, to Adel Zaitri (@adelzaitri) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance.
If anything is unclear, ask below.
github.com
adelzaitri - Overview
Security researcher & engineer | CISSP | Incoming PhD student in Offensive Cyber Engineering - adelzaitri
@hongminhee@hollo.social
A security update has been released to address multiple Hollo security vulnerabilities. Please update as soon as possible!
https://hollo.social/@hollo/01a1493c-36f9-7992-a6e9-5d10cd3201b7
hollo.social
### Hollo security updates: 0.…
### Hollo security updates: 0.8.16 and 0.9.24 If you run Hollo, update to [0.8.16] or [0.9.24] now. These releases fix [GHSA-v2qh-w789-xxj6], a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use. For [GHSA-v2qh-w789-xxj6], an authenticated client with the `write:statuses` scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check. For [GHSA-97w4-f4rq-mgqm], Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were [0.8.13] and [0.9.20], incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected. For [GHSA-4qhx-hhwf-8685], Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache. For [GHSA-8863-8468-7hq7], Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually. Both of these authentication fixes first reached Hollo in [0.8.15] and [0.9.23], incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too. The other Fedify advisory, [GHSA-39gj-rchc-q5m3], concerns `Context.routeActivity()`: after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in [0.8.14] and [0.9.21]. For full technical details on the upstream issues, see the linked advisories and the [October 4 Fedify announcement] and [October 16 Fedify announcement]. The supported Hollo release lines are 0.8.x and 0.9.x under the [Hollo security policy]. Operators on 0.7.x or earlier should move to a supported line. For 0.8.x deployments, update to [0.8.16]: ~~~~ bash docker pull ghcr.io/fedify-dev/hollo:0.8.16 ~~~~ For 0.9.x deployments, update to [0.9.24]: ~~~~ bash docker pull ghcr.io/fedify-dev/hollo:0.9.24 ~~~~ After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run `docker compose up -d`. For source deployments, check out the corresponding release tag, run `pnpm install --frozen-lockfile` with that tag's pinned pnpm version, run `pnpm run build`, and restart the server. If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the [0.9.20 index preparation instructions] before starting the new version to avoid blocking writes during its automatic migration. Thanks to Yami Odymel (@yamiodymel@misskey.io) for reporting the status deletion issue to Hollo, to Adel Zaitri ([@adelzaitri]) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng@hackers.pub) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance. If anything is unclear, ask below. [0.8.16]: https://github.com/fedify-dev/hollo/releases/tag/0.8.16 [0.9.24]: https://github.com/fedify-dev/hollo/releases/tag/0.9.24 [GHSA-v2qh-w789-xxj6]: https://github.com/fedify-dev/hollo/security/advisories/GHSA-v2qh-w789-xxj6 [GHSA-97w4-f4rq-mgqm]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-97w4-f4rq-mgqm [0.8.13]: https://github.com/fedify-dev/hollo/releases/tag/0.8.13 [0.9.20]: https://github.com/fedify-dev/hollo/releases/tag/0.9.20 [GHSA-4qhx-hhwf-8685]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-4qhx-hhwf-8685 [GHSA-8863-8468-7hq7]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-8863-8468-7hq7 [0.8.15]: https://github.com/fedify-dev/hollo/releases/tag/0.8.15 [0.9.23]: https://github.com/fedify-dev/hollo/releases/tag/0.9.23 [GHSA-39gj-rchc-q5m3]: https://github.com/fedify-dev/fedify/security/advisories/GHSA-39gj-rchc-q5m3 [0.8.14]: https://github.com/fedify-dev/hollo/releases/tag/0.8.14 [0.9.21]: https://github.com/fedify-dev/hollo/releases/tag/0.9.21 [October 4 Fedify announcement]: https://github.com/fedify-dev/fedify/discussions/1221 [October 16 Fedify announcement]: https://github.com/fedify-dev/fedify/discussions/1301 [Hollo security policy]: https://github.com/fedify-dev/hollo/blob/main/SECURITY.md [0.9.20 index preparation instructions]: https://github.com/fedify-dev/hollo/blob/0.9.24/CHANGES.md#version-0920 [@adelzaitri]: https://github.com/adelzaitri
@hollo@hollo.social
Hollo security updates: 0.8.16 and 0.9.24
If you run Hollo, update to 0.8.16 or 0.9.24 now. These releases fix GHSA-v2qh-w789-xxj6, a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use.
For GHSA-v2qh-w789-xxj6, an authenticated client with the write:statuses scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check.
For GHSA-97w4-f4rq-mgqm, Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were 0.8.13 and 0.9.20, incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected.
For GHSA-4qhx-hhwf-8685, Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache.
For GHSA-8863-8468-7hq7, Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually.
Both of these authentication fixes first reached Hollo in 0.8.15 and 0.9.23, incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too.
The other Fedify advisory, GHSA-39gj-rchc-q5m3, concerns Context.routeActivity(): after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in 0.8.14 and 0.9.21. For full technical details on the upstream issues, see the linked advisories and the October 4 Fedify announcement and October 16 Fedify announcement.
The supported Hollo release lines are 0.8.x and 0.9.x under the Hollo security policy. Operators on 0.7.x or earlier should move to a supported line.
For 0.8.x deployments, update to 0.8.16:
docker pull ghcr.io/fedify-dev/hollo:0.8.16For 0.9.x deployments, update to 0.9.24:
docker pull ghcr.io/fedify-dev/hollo:0.9.24After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile with that tag's pinned pnpm version, run pnpm run build, and restart the server.
If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during its automatic migration.
Thanks to Yami Odymel (@yamiodymel) for reporting the status deletion issue to Hollo, to Adel Zaitri (@adelzaitri) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance.
If anything is unclear, ask below.
github.com
adelzaitri - Overview
Security researcher & engineer | CISSP | Incoming PhD student in Offensive Cyber Engineering - adelzaitri
@hollo@hollo.social
Hollo security updates: 0.8.16 and 0.9.24
If you run Hollo, update to 0.8.16 or 0.9.24 now. These releases fix GHSA-v2qh-w789-xxj6, a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use.
For GHSA-v2qh-w789-xxj6, an authenticated client with the write:statuses scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check.
For GHSA-97w4-f4rq-mgqm, Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were 0.8.13 and 0.9.20, incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected.
For GHSA-4qhx-hhwf-8685, Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache.
For GHSA-8863-8468-7hq7, Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually.
Both of these authentication fixes first reached Hollo in 0.8.15 and 0.9.23, incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too.
The other Fedify advisory, GHSA-39gj-rchc-q5m3, concerns Context.routeActivity(): after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in 0.8.14 and 0.9.21. For full technical details on the upstream issues, see the linked advisories and the October 4 Fedify announcement and October 16 Fedify announcement.
The supported Hollo release lines are 0.8.x and 0.9.x under the Hollo security policy. Operators on 0.7.x or earlier should move to a supported line.
For 0.8.x deployments, update to 0.8.16:
docker pull ghcr.io/fedify-dev/hollo:0.8.16For 0.9.x deployments, update to 0.9.24:
docker pull ghcr.io/fedify-dev/hollo:0.9.24After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile with that tag's pinned pnpm version, run pnpm run build, and restart the server.
If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during its automatic migration.
Thanks to Yami Odymel (@yamiodymel) for reporting the status deletion issue to Hollo, to Adel Zaitri (@adelzaitri) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance.
If anything is unclear, ask below.
github.com
adelzaitri - Overview
Security researcher & engineer | CISSP | Incoming PhD student in Offensive Cyber Engineering - adelzaitri
@AureoleArk@misskey.io
Fediverseって言うのがあるんですね！
始めてみようかな！
@parksb@silicon.moe
"거의 모든 계엄, 탄핵 관련 지표에서 청년 남성은 가장 친계엄적이고, 민주주의 질서에 가장 비우호적인 태도로 변화하였다. 우리 논문에서는 민주주의에 대한 태도에서 청년 남성과 86세대를 포함한 장년 남성 사이에 차이가 없다고 했었는데, 이제는 차이가 벌어졌고, 청년 남성은 노년 남성과 차이가 없거나 오히려 더 반민주주의적이다." https://sovidence.tistory.com/1332
ALT text
‘12·3 비상계엄은 정당했다’는 응답률의 변화를 성별과 연령대별로 비교한 선그래프. 조사 시점은 2025년 2월 계엄 직후, 2025년 6월 대선 직후, 2026년 6월 지방선거 직후다. 가장 큰 변화는 18~34세 남성에서 나타난다. 이 집단의 응답률은 2025년 2월 약 18%에서 6월 약 13%로 낮아졌다가, 2026년 6월 약 35%로 크게 상승해 모든 집단 중 가장 높다. 65세 이상 여성은 약 36%, 18%, 27%, 65세 이상 남성은 약 31%, 19%, 26%로 두 집단 모두 2025년 6월에 크게 하락한 뒤 다시 상승한다. 35~64세 남성은 약 17%, 11%, 14%, 18~34세 여성은 약 5%, 7%, 12%, 35~64세 여성은 약 13%, 9%, 10%다. 전반적으로 2025년 6월에는 대부분 집단의 응답률이 낮아졌고, 2026년 6월에는 다시 상승했으며 특히 18~34세 남성의 상승이 두드러진다.
@hongminhee@hollo.social · Reply to 花飛蒜頭貓
@Yoxem Yes, I think it's probably because, during the Japanese colonial period, Japanese kyūjitai (舊字體) forms influenced the standard forms of hanja adopted in Korea after liberation. 🤔
@hongminhee@hollo.social
韓國과 日本에서는 漢字 【낳을 산】을 普通 「産」으로 적는 反面, 臺灣이나 香港 等 이른바 繁體字圈서는 「產」을 標準 字形으로 삼는다. 個人的으로는 윗 部分이 文이므로 「產」으로 적는 것을 選好하긴 한다.
@botkit@hackers.pub
If you use BotKit, update to a patched release now. This update addresses two vulnerabilities: GHSA-4qhx-hhwf-8685, an inbox origin validation flaw that could let an attacker supply forged objects or suppress genuine activities, and GHSA-8863-8468-7hq7, a key ownership validation flaw that could authenticate activities as the wrong actor under specific actor-document configurations. Both flaws originate in Fedify, which BotKit uses for federation.
GHSA-4qhx-hhwf-8685 affects incoming activities. Fedify authenticated the activity's actor but did not require the activity's id to share that actor's origin. An attacker needed only an actor and its signing key on a server they controlled, with no account on the receiving server or interaction from the victim.
By choosing an activity ID on another server's origin, the attacker could make Create.getObject() and other accessors return embedded objects claiming to live on that server without fetching them from it. BotKit checks that a message's attribution matches the activity's actor, but that does not stop an attacker from attributing an object to themselves while giving it an ID on another server. Its handlers could therefore receive forged objects under that server's object IDs. The same flaw also let an attacker who knew or could predict a genuine activity's ID reserve its idempotency cache entry by sending a forged activity with that ID first. The genuine delivery then received 202 Accepted but did not reach the inbox listeners for one day. With a message queue, this suppression applied across all inboxes on the receiving server.
The fix rejects non-portable activities whose IDs have a different origin from their actors before they reach inbox listeners, the queue, or the idempotency cache. The same origin check runs when processing activities from the queue or routing them manually.
GHSA-8863-8468-7hq7 affects Fedify's checks that a signing key belongs to an actor. Fedify fetched the actor's document and checked that it listed the key, but did not require the document's id to match the actor ID it requested. An attacker could have activities authenticated as a victim if dereferencing the victim's exact actor ID led to an actor document whose key the attacker controlled. This could happen through a redirect or alternate-document link, including to another origin, or when the victim's server directly served another same-origin actor's document.
The attacker cannot normally arrange this condition: it depends on the server hosting the victim's actor ID. A redirect from some other URL on that server is not enough. HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs use the affected ownership checks.
The fix requires the fetched actor document's id to exactly match the requested actor ID. Fedify also retains its check that the document's id shares the origin of the final fetched URL. An actor whose ID redirects to a document with a different id can no longer have its keys confirmed through that redirect, even on the same origin and for the same account. Fedify's built-in key cache automatically ignores entries created under the weaker check and fetches and verifies those keys again. If your application separately supplies a custom KeyCache implementation to Fedify, clear it once when upgrading so previously cached false ownership claims are not retained.
BotKit 0.4.x versions through 0.4.9 and BotKit 0.5.x versions through 0.5.6 include Fedify versions affected by both vulnerabilities. The first patched releases, and the current recommended releases, are BotKit 0.4.10 and 0.5.7. BotKit 0.4.10 requires Fedify ~2.1.30, and BotKit 0.5.7 requires Fedify ~2.3.14. These are the two supported BotKit lines; users on older lines should move to a supported release.
For BotKit 0.5.x, install @fedify/botkit 0.5.7 using the command for your package manager:
npm install @fedify/botkit@0.5.7
yarn add @fedify/botkit@0.5.7
pnpm add @fedify/botkit@0.5.7
bun add @fedify/botkit@0.5.7
deno add jsr:@fedify/botkit@0.5.7For BotKit 0.4.x, install @fedify/botkit 0.4.10:
npm install @fedify/botkit@0.4.10
yarn add @fedify/botkit@0.4.10
pnpm add @fedify/botkit@0.4.10
bun add @fedify/botkit@0.4.10
deno add jsr:@fedify/botkit@0.4.10Check the installed or locked versions: @fedify/botkit should be 0.4.10 or 0.5.7, with @fedify/fedify at least 2.1.30 on the 2.1.x line or 2.3.14 on the 2.3.x line. If you use a routine update command instead, check that your declared dependency range allows the patched release and change it explicitly if needed. After updating, redeploy.
The full GitHub Security Advisories are GHSA-4qhx-hhwf-8685 and GHSA-8863-8468-7hq7. See also Fedify's own announcement.
Thanks to @2chanhaeng for reporting the inbox origin validation flaw to the Fedify project. The actor document identity mismatch was found by the Fedify maintainers with AI assistance.
If anything is unclear, feel free to ask on GitHub Discussions or Matrix.
matrix.to
You're invited to talk on Matrix
You're invited to talk on Matrix
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:
Fedifyの2件のセキュリティ脆弱性に対するセキュリティアップデートがリリースされました。早急にアップデートしてください！
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:
Fedify 保安 脆弱點 2件에 對한 保安 업데이트가 릴리스되었으니, 早速히 업데이트 바랍니다!
@lobsters@mastodon.social
Furifont: furigana built into the font via @hongminhee https://lobste.rs/s/ixoasm #design
https://furifont.antfu.me/
furifont.antfu.me
Furifont: furigana built into the font
A Japanese font that shows furigana by itself.
@hongminhee@hollo.social
A security update addressing two vulnerabilities in Fedify has been released. Please update as soon as possible!
hackers.pub
Fedify security updates: 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4
Critical security vulnerabilities have been patched in the `@fedify/fedify` package, addressing flaws in inbox origin validation and actor key ownership verification. The first vulnerability, GHSA-4qhx-hhwf-8685, allowed attackers to provide forged embedded objects or suppress genuine activities through idempotency cache abuse due to missing origin checks between activity IDs and their actors. The second vulnerability, GHSA-8863-8468-7hq7, allowed improper authentication under specific actor document redirect or alternate-document configurations when dereferencing keys. Fixes have rolled out across versions 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4, enforcing strict origin matching and document ID equality while automatically invalidating affected built-in cache entries. Upgrading immediately and clearing any custom key caches is essential to protecting Fedify-powered federated applications from activity suppression and identity spoofing.
@fedify@hackers.pub
If you use an affected Fedify release, update now. Two vulnerabilities have been fixed in @fedify/fedify: GHSA-4qhx-hhwf-8685, an inbox origin validation flaw that could let an attacker supply forged objects or suppress genuine activities, and GHSA-8863-8468-7hq7, a flaw in the key ownership check that could authenticate activities as the wrong actor under specific actor-document configurations.
The releases containing both fixes are 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4. We recommend 2.4.4, or 2.3.14 if you are staying on the 2.3 line. Under the security policy, Fedify supports the latest two minor lines, currently 2.4 and 2.3. Backported fixes are also available in the releases listed above for 2.0, 2.1, and 2.2, but users on those older lines should plan to move to a supported line. Users on affected 1.x releases need to change their dependency to a supported 2.x release.
Inbox activity origin mismatch (GHSA-4qhx-hhwf-8685, medium, CVSS 6.5)
GHSA-4qhx-hhwf-8685 affects applications receiving activities through Fedify's inbox listeners. The inbox authenticated an activity's actor but accepted an activity id on an origin different from the actor's. An attacker needed only an actor and its signing key on a server they controlled, with no account on the receiving server or interaction from the victim.
Since version 1.9.0, Fedify's property accessors have trusted embedded objects whose IDs share the activity's origin. By choosing an activity ID on a victim server's origin, an attacker could make Create.getObject() and other accessors return forged objects claiming to live on that server without fetching them from it. Depending on the application's attribution and authorization checks, this could cause it to store or display forged content under another server's object ID.
The same missing check also let an attacker reserve a genuine activity's idempotency cache entry by submitting a forged activity with its ID first. The genuine delivery then received 202 Accepted but did not reach the listeners for one day. When a message queue was configured, the suppression applied across all inboxes on the receiving server. This behavior was confirmed in 1.8.15 and subsequent releases before the fixes; releases before 1.8 were not tested.
The first fixes shipped in 2.0.33, 2.1.29, 2.2.18, 2.3.13, and 2.4.3. Earlier releases on each of those 2.x lines are affected. Update to the newer releases recommended above to receive both fixes. The inbox now returns 401 Unauthorized for non-portable activities whose IDs have a different origin from their actors, before they reach listeners, the queue, or the idempotency cache. The same origin check applies to queued and manually routed activities. Setting skipSignatureVerification bypasses this protection along with signature verification.
Actor document identity mismatch (GHSA-8863-8468-7hq7, medium, CVSS 5.9)
GHSA-8863-8468-7hq7 lists the affected version range as <= 2.4.3, with fixes in 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4 on their respective release lines. When confirming that a key belongs to an actor, Fedify fetched the actor's document and checked that it listed the key, but did not require the document's id to match the actor ID it requested.
An attacker could have activities authenticated as a victim if dereferencing the victim's exact actor ID led to an actor document whose key the attacker controlled. This could happen through a redirect or alternate-document link to the attacker's document, including on another origin, or when the victim's server directly served a different same-origin actor's document. The attacker cannot normally arrange this: it depends on the server hosting the victim's actor ID. A redirect from some other URL on that server is not enough. No account on the receiving Fedify server is required.
HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs use the affected ownership checks. The fix requires the fetched actor document's id to exactly match the requested actor ID, in addition to the existing origin check. An actor whose ID redirects to a document with a different id can no longer have its keys confirmed through that redirect, even on the same origin and for the same account. Servers that normalize actor URLs should use the canonical actor ID as their keys' owner or controller and their activities' actor.
The built-in KvStore-backed key cache automatically ignores entries created under the weaker check and fetches and verifies those keys again. If you supply a custom KeyCache implementation, clear it once when upgrading. Otherwise, previously cached false ownership claims can remain trusted after the upgrade. Downgrading to an earlier release is not safe.
Updating
Update @fedify/fedify using the command for your package manager:
npm update @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update @fedify/fedify
bun update @fedify/fedify
deno update @fedify/fedifyCheck the installed or locked version: it should be 2.0.34, 2.1.30, 2.2.19, 2.3.14, or 2.4.4 on the corresponding line. Update commands can stay within your declared dependency range. If that range excludes the recommended release, change it explicitly. For example, to move to 2.4.4:
npm install @fedify/fedify@2.4.4
yarn add @fedify/fedify@2.4.4
pnpm add @fedify/fedify@2.4.4
bun add @fedify/fedify@2.4.4
deno add jsr:@fedify/fedify@2.4.4Clear any custom key cache as described above, then redeploy. If you run other Fedify-based servers, update those too.
The full GitHub Security Advisories are GHSA-4qhx-hhwf-8685 and GHSA-8863-8468-7hq7.
Thanks to @2chanhaeng for reporting the inbox activity origin mismatch. The actor document identity mismatch was found by the Fedify maintainers with AI assistance.
If anything is unclear, ask below.
github.com
Key ownership checks accept a different actor's document when resolving an actor ID
### Summary The fix for GHSA-q9f8-5hc7-898f made Fedify confirm a key's claimed owner by fetching the owner's actor document and checking that it lists the key. That check accepts whatever actor ...
@fedify@hackers.pub
If you use an affected Fedify release, update now. Two vulnerabilities have been fixed in @fedify/fedify: GHSA-4qhx-hhwf-8685, an inbox origin validation flaw that could let an attacker supply forged objects or suppress genuine activities, and GHSA-8863-8468-7hq7, a flaw in the key ownership check that could authenticate activities as the wrong actor under specific actor-document configurations.
The releases containing both fixes are 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4. We recommend 2.4.4, or 2.3.14 if you are staying on the 2.3 line. Under the security policy, Fedify supports the latest two minor lines, currently 2.4 and 2.3. Backported fixes are also available in the releases listed above for 2.0, 2.1, and 2.2, but users on those older lines should plan to move to a supported line. Users on affected 1.x releases need to change their dependency to a supported 2.x release.
Inbox activity origin mismatch (GHSA-4qhx-hhwf-8685, medium, CVSS 6.5)
GHSA-4qhx-hhwf-8685 affects applications receiving activities through Fedify's inbox listeners. The inbox authenticated an activity's actor but accepted an activity id on an origin different from the actor's. An attacker needed only an actor and its signing key on a server they controlled, with no account on the receiving server or interaction from the victim.
Since version 1.9.0, Fedify's property accessors have trusted embedded objects whose IDs share the activity's origin. By choosing an activity ID on a victim server's origin, an attacker could make Create.getObject() and other accessors return forged objects claiming to live on that server without fetching them from it. Depending on the application's attribution and authorization checks, this could cause it to store or display forged content under another server's object ID.
The same missing check also let an attacker reserve a genuine activity's idempotency cache entry by submitting a forged activity with its ID first. The genuine delivery then received 202 Accepted but did not reach the listeners for one day. When a message queue was configured, the suppression applied across all inboxes on the receiving server. This behavior was confirmed in 1.8.15 and subsequent releases before the fixes; releases before 1.8 were not tested.
The first fixes shipped in 2.0.33, 2.1.29, 2.2.18, 2.3.13, and 2.4.3. Earlier releases on each of those 2.x lines are affected. Update to the newer releases recommended above to receive both fixes. The inbox now returns 401 Unauthorized for non-portable activities whose IDs have a different origin from their actors, before they reach listeners, the queue, or the idempotency cache. The same origin check applies to queued and manually routed activities. Setting skipSignatureVerification bypasses this protection along with signature verification.
Actor document identity mismatch (GHSA-8863-8468-7hq7, medium, CVSS 5.9)
GHSA-8863-8468-7hq7 lists the affected version range as <= 2.4.3, with fixes in 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4 on their respective release lines. When confirming that a key belongs to an actor, Fedify fetched the actor's document and checked that it listed the key, but did not require the document's id to match the actor ID it requested.
An attacker could have activities authenticated as a victim if dereferencing the victim's exact actor ID led to an actor document whose key the attacker controlled. This could happen through a redirect or alternate-document link to the attacker's document, including on another origin, or when the victim's server directly served a different same-origin actor's document. The attacker cannot normally arrange this: it depends on the server hosting the victim's actor ID. A redirect from some other URL on that server is not enough. No account on the receiving Fedify server is required.
HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs use the affected ownership checks. The fix requires the fetched actor document's id to exactly match the requested actor ID, in addition to the existing origin check. An actor whose ID redirects to a document with a different id can no longer have its keys confirmed through that redirect, even on the same origin and for the same account. Servers that normalize actor URLs should use the canonical actor ID as their keys' owner or controller and their activities' actor.
The built-in KvStore-backed key cache automatically ignores entries created under the weaker check and fetches and verifies those keys again. If you supply a custom KeyCache implementation, clear it once when upgrading. Otherwise, previously cached false ownership claims can remain trusted after the upgrade. Downgrading to an earlier release is not safe.
Updating
Update @fedify/fedify using the command for your package manager:
npm update @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update @fedify/fedify
bun update @fedify/fedify
deno update @fedify/fedifyCheck the installed or locked version: it should be 2.0.34, 2.1.30, 2.2.19, 2.3.14, or 2.4.4 on the corresponding line. Update commands can stay within your declared dependency range. If that range excludes the recommended release, change it explicitly. For example, to move to 2.4.4:
npm install @fedify/fedify@2.4.4
yarn add @fedify/fedify@2.4.4
pnpm add @fedify/fedify@2.4.4
bun add @fedify/fedify@2.4.4
deno add jsr:@fedify/fedify@2.4.4Clear any custom key cache as described above, then redeploy. If you run other Fedify-based servers, update those too.
The full GitHub Security Advisories are GHSA-4qhx-hhwf-8685 and GHSA-8863-8468-7hq7.
Thanks to @2chanhaeng for reporting the inbox activity origin mismatch. The actor document identity mismatch was found by the Fedify maintainers with AI assistance.
If anything is unclear, ask below.
github.com
Key ownership checks accept a different actor's document when resolving an actor ID
### Summary The fix for GHSA-q9f8-5hc7-898f made Fedify confirm a key's claimed owner by fetching the owner's actor document and checking that it lists the key. That check accepts whatever actor ...