Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.
I work full-time on @fedify, an ActivityPub server framework in TypeScript, funded by @sovtechfund. I'm also the creator of @hollo, a single-user ActivityPub microblog; @botkit, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.
I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!
安寧하세요! 저는 서울에 살고 있는 30代 後半의 오픈 소스 소프트웨어 엔지니어 洪民憙입니다. 兩性愛者(bisexual)이자 논바이너리(non-binary)이며, 自由·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(fediverse)의 熱烈한 支持者이기도 합니다.
STF(@sovtechfund)의 支援을 받아 TypeScript用 ActivityPub 서버 프레임워크 @fedify 開發에 專業으로 任하고 있습니다. 그 外에도 싱글 유저用 ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者를 위한 聯合宇宙 플랫폼 Hackers' Pub, JavaScript·TypeScript用 로깅 라이브러리 LogTape 等의 製作者이기도 합니다.
東아시아 言語(이른바 CJK)와 Unicode에도 關心이 많습니다. 이 計定에서는 主로 英語로 포스팅하지만, 때때로 日本語나 國漢文混用體 韓國語로도 씁니다. 聯合宇宙에 오게 된 動機 中 하나가 바로 國漢文混用體로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語, 英語, 日本語, 아니면 漢文으로도 말을 걸어주세요!
國漢文을 한글로 바꿔주는 소프트웨어인 Gukhanmun 0.2.0이 릴리스되었습니다. 《標準國語大辭典》과 더불어 《우리말샘》 데이터를 包含하게 되었고, 各種 코너 케이스를 더 잘 다루게 되었습니다. 또한, 國漢文 原文에 括弧로 한글 倂記가 되어 있을 境遇, 이를 結果文에서도 反映하여 漢字 倂記가 되거나 한글 讀音이 달리게 되었습니다. 그 밖에도 여러 改善 事項들이 있으니, 仔細한 內容은 릴리스 노트를 參考하시기 바랍니다.
I write my name in Chinese characters: 洪民憙. In English I still include them, writing Hong Minhee (洪民憙) rather than the romanization alone.
Part of it is meaning: Chinese characters carry it, hangul doesn't. Mostly, though, it's about the direction of loss. You can derive a Korean or romanized reading from 洪民憙; you can't go the other way. Given 홍민희 or Hong Minhee alone, there's no recovering which characters were intended.
I don't much mind how my name gets pronounced. If a Chinese speaker reads it as Hóng Mǐnxī, or a Japanese speaker arrives at something different, that's fine. The characters are the same. Classical Chinese once worked this way across East Asia: one written text, many readings.
과학기술정보통신부 및 정보통신산업진흥원(NIPA)에서 주최하는 오픈 소스 컨트리뷰션 아카데미 (OSSCA) 참여형 프로그램 멘티를 모집합니다. OSSCA는 평소 오픈 소스에 관심은 있었지만 어떻게 참여해야 할 지 막막하셨던 분들께 몇 개월에 걸쳐 구체적으로 참여하는 요령을 알려드리는 프로그램입니다. 실제로 이 과정을 계기로 오픈 소스 프로젝트의 메인테이너들과 교류하게 되고, 본격적으로 오픈 소스 기여를 시작하게 되는 분들도 많습니다.
저희 Fedify 프로젝트도 작년에 이어 올해도 OSSCA에서 만나보실 수 있는데요, 작년에 멘티셨던 권지원 님(@z9mb1), 이재열 님(@kodingwarrior), 이찬행 님(@2chanhaeng)이 저와 함께 멘토로 참여하게 되었습니다. 세 분 모두 작년 OSSCA를 통해 Fedify에 본격적으로 참여하게 된 케이스입니다. 여러분도 이런 식으로 평소 관심만 있던 오픈 소스에 실제로 기여도 하고, 아예 본격적으로 참여하실 수도 있습니다.
제가 멘토라서 하는 얘기가 아니라, 정말 좋은 기회라고 생각합니다. 학생·직장인 무관하게 지원 가능하니, 관심 있는 분들의 많은 참여 부탁드립니다! → 참가 신청
It shows so clearly that plain HTML and some JS and CSS are powerful enough for most tasks we do online, and result in superior experiences for everyone.
It's this kind outcome that drives me to build BackflipHTML.
I've told this story at conferences - but due to the general situation I thought I'd retell it here.
A few years ago I was doing policy research in a housing benefits office in London. They are singularly unlovely places. The walls are brightened up with posters offering helpful services for people fleeing domestic violence. The security guards on the door are cautiously indifferent to anyone walking in. The air is filled with tense conversations between partners - drowned out by the noise of screaming kids.
In the middle, a young woman sits on a hard plastic chair. She is surrounded by canvas-bags containing her worldly possessions. She doesn't look like she is in a great emotional place right now. Clutched in her hands is a games console - a PlayStation Portable. She stares at it intensely; blocking out the world with Candy Crush.
Or, at least, that's what I thought.
Walking behind her, I glance at her console and recognise the screen she's on. She's connected to the complementary WiFi and is browsing the GOV.UK pages on Housing Benefit. She's not slicing fruit; she's arming herself with knowledge.
The PSP's web browser is - charitably - pathetic. It is slow, frequently runs out of memory, and can only open 3 tabs at a time.
But the GOV.UK pages are written in simple HTML. They are designed to be lightweight and will work even on rubbish browsers. They have to. This is for everyone.
Not everyone has a big monitor, or a multi-core CPU burning through the teraflops, or a broadband connection.
The photographer Chase Jarvis coined the phrase "the best camera is the one that’s with you". He meant that having a crappy instamatic with you at an important moment is better than having the best camera in the world locked up in your car.
The same is true of web browsers. If you have a smart TV, it probably has a crappy browser.
If your laptop and phone both got stolen - how easily could you conduct online life through the worst browser you have? If you have to file an insurance claim online - will you get sent a simple HTML form to fill in, or a DOCX which won't render?
What vital information or services are forbidden to you due to being trapped in PDFs or horrendously complicated web sites?
Are you developing public services? Or a system that people might access when they're in desperate need of help? Plain HTML works. A small bit of simple CSS will make look decent. JavaScript is probably unnecessary - but can be used to progressively enhance stuff. Add alt text to images so people paying per MB can understand what the images are for (and, you know, accessibility).
Go sit in an uncomfortable chair, in an uncomfortable location, and stare at an uncomfortably small screen with an uncomfortably outdated web browser. How easy is it to use the websites you've created?
I chatted briefly to the young woman afterwards. She'd been kicked out by her parents and her friends had given her the bus fare to the housing benefits office. She had nothing but praise for how helpful the staff had been. I asked about the PSP - a hand-me-down from an older brother - and the web browser. Her reply was "It's shit. But it worked."
I think that's all we can strive for.
Here are some stats on games consoles visiting GOV.UK
Replying to @TheRealNooshuInterestingly we have 3,574 users visiting GOV.UK on games consoles: • Xbox - 2,062 • Playstation 4 - 1,457 • Playstation Vita - 25 • Nintendo WiiU - 14 • Nintendo 3DS - 16
GPKI 루트 인증서는 주로 정부에서 .go.kr TLD를 비롯한 여러 국공립 웹 사이트의 도메인에 인증서를 발급하는데 주로 사용돼었습니다. (과거형 임에 유의, 현재는 정부 사이트들이 각자 다른 업체로부터 인증서를 발급 받아서 HTTPS 서비스 제공 중)
타 브라우저와 달리 Firefox는 자체적인 루트 인증서 목록을 갖고 있고 TLS 연결 시 운영체제의 인증서 목록을 따르지 않습니다. 예를 들어 Windows의 경우 GPKI 인증서가 선탑재돼있지만 Firefox는 그걸 읽지 않습니다. (다만, 요즘에는 about:config 설정 페이지의 보안 탭에서 체크박스 하나로 쉽게 변경하여 따르도록 할 수 있음) …**
I am working on my Laravel-Activitypub package, it will replace federation support in Pixelfed once all tests are passing!
To demonstrate and test it before we use it in Pixelfed, a small and simple single user photo sharing server will be published and I'll boost the first photo here.
the cyberpunk present is weird as fuck: the latest Shai Hulud malware wave contains an LLM prompt to create biological weapons and nuclear weapons, with the purpose to trip LLM safety refusals so that LLM-based code scanning wont see the malware
@silverpill Yeah, I think that is a fair distinction. Documentation and multicast ranges are not the main practical SSRF targets here, especially for ordinary HTTP fetching.
The practical risk is clearer for ranges like 100.64.0.0/10, 198.18.0.0/15, and IPv6 translation/tunneling prefixes, which can map to provider, VPN, lab, Kubernetes, or enterprise-internal networks. A request made by the Fedify server may reach something the attacker cannot reach directly.
For documentation ranges, the “in theory” case would be a non-compliant internal network using TEST-NET addresses. For multicast, I would mostly treat it as a correctness/fail-closed issue rather than a likely standalone exploit.
The security bug is that validatePublicUrl() was an SSRF boundary but did not enforce public/global address semantics. At that boundary, I do not think we should maintain a list of “non-public but probably harmless” exceptions. If it is not globally routable public address space, the fetch should be rejected.
@silverpill The dangerous case is not that every one of those ranges is equally exploitable. For example, the documentation ranges are mostly a correctness signal.
The real concern is that this function is an SSRF boundary. Once Fedify decides “this URL is public enough to fetch,” the request is made from the server's network, not from the attacker's network.
A realistic example would be a Fedify server running in an environment where 100.64.0.0/10 is used for provider, VPN, Kubernetes, or internal service networking. If an attacker can put a URL like https://100.64.0.10/... in a remote ActivityPub object or media URL, and Fedify classifies that address as public, the Fedify server may send a request to something only reachable from inside that deployment. That could be an internal HTTP service, proxy, metadata endpoint, admin panel, or just a host that reveals reachability through timing or errors.
Similar reasoning applies to ranges like 198.18.0.0/15 in lab or benchmarking networks, and to IPv6 translation/tunneling prefixes where an address can map back to a private IPv4 destination.
So I would not phrase it as “documentation or multicast addresses are always practical SSRF targets.” The issue is that a security check whose job is to allow only public internet destinations was accepting addresses that are not public internet destinations. For SSRF mitigation, that should fail closed: allow globally routable public addresses, reject the rest.
If you use BotKit, update to a patched release now. CVE-2026-50131 affects Fedify's SSRF protection for remote document and media loading, and BotKit inherits the exposure through its dependency on Fedify.
Fedify validates remote ActivityPub document and media URLs before fetching them, including direct IP literals and hostnames resolved through DNS, to protect against Server-Side Request Forgery (SSRF). The vulnerable path is validatePublicUrl(): affected versions rejected common private and local addresses, but still treated several special-use IPv4 ranges—including carrier-grade NAT, benchmarking, multicast, reserved, and documentation networks—as public internet destinations. An attacker could use these special-use IP address ranges to bypass Fedify's SSRF protections and cause a BotKit server to initiate requests to non-public or special-use network destinations, depending on the deployment environment and network routing.
The fix makes Fedify validate resolved addresses against public-network expectations instead of relying on the incomplete denylist. It rejects additional special-use IPv4 ranges before remote document or media fetching proceeds.
All versions of BotKit up to 0.3.3 (in the 0.3.x branch) and 0.4.2 (in the 0.4.x branch) are affected. Patched releases are 0.3.4 and 0.4.3.
If you run Hollo, update to a patched release now. CVE-2026-50131 affects Fedify's SSRF protection, and Hollo depends on Fedify for ActivityPub federation.
Fedify guards against SSRF (Server-Side Request Forgery) when fetching remote ActivityPub objects, documents, and media by validating that the resolved destination is a public IP address. The previous SSRF fix (GHSA-p9cg-vqcc-grcx) blocked common private and local ranges such as 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, and 192.168.0.0/16, but the validation was incomplete—it still treated several special-use IPv4 ranges as public destinations that should have been rejected. These include carrier-grade NAT (100.64.0.0/10), benchmarking and internal testing networks (198.18.0.0/15), multicast (224.0.0.0/4), reserved (240.0.0.0/4), IETF protocol assignments (192.0.0.0/24), and documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24).
An attacker who controls a remote ActivityPub object or media URL could therefore cause a Hollo instance to initiate outbound requests to non-public or special-use network ranges, depending on the deployment environment and network routing.
All Hollo versions up to and including 0.7.17, 0.8.6, and 0.9.3 are affected. Patched releases are 0.7.18 for the 0.7.x series, 0.8.7 for the 0.8.x series, and 0.9.4 for the 0.9.x series.
Fedify security updates: 1.9.12, 1.10.11, 2.0.20, 2.1.16, and 2.2.5
If you use Fedify, update to a patched release now. CVE-2026-50131 affects Fedify's public URL validation for remote document and media loading. An attacker could use special-use IP address ranges to bypass Fedify's SSRF protections and cause a Fedify server to initiate requests to non-public or special-use network destinations, depending on the deployment environment and network routing.
Fedify validates remote ActivityPub document and media URLs before fetching them, including direct IP literals and hostnames resolved through DNS. The vulnerable path is validatePublicUrl(): affected versions rejected common private and local addresses, but still treated several special-use IPv4 ranges as public internet destinations. That gap could allow outbound requests to ranges such as carrier-grade NAT, benchmarking, multicast, reserved, and documentation networks.
The fix makes Fedify validate resolved addresses against public-network expectations instead of relying on the incomplete denylist. It rejects additional special-use IPv4 ranges and IPv6 translation or tunneling prefixes, including NAT64, Teredo, and 6to4 addresses, before remote document or media fetching proceeds.
