洪 民憙 (Hong Minhee)

그러고 보면 이듬해 돌아가신 아버지는 離別(이별)을 받아들이기까지 그리 오래 걸리지 않았는데, 어머니는 꽤 오래 붙잡고 있었던 것 같다.

오늘 오랜만에 꿈에 어머니가 나오셨다.

葬禮(장례) 以後(이후)로 꿈에서는 언제나 어머니가 어째서인지 줄곧 살아 계셨는데, 그게 참 多幸(다행)이라 여기면서도 어떻게 다시 살아 돌아오실 수 있었을까 궁금했다. 하지만 다시 돌아가실까봐 여쭤보진 못하고 조마조마한 마음으로 어머니와 함께 있는 時間(시간)을 지냈던 것 같다.

그런데 오늘은 어쩐지 어머니께 葬禮(장례)까지 치렀는데 어떻게 다시 살아 돌아오셨는지 여쭤야겠다는 마음이 들었다. 동생(아주 어릴 때 모습이었다)도 그러자고 고개를 끄덕였다.

엄마, 근데 어떻게 아직 살아 계신 거예요? 이제 다시 돌아가시진 않을 거죠?

그렇게 여쭸더니 어머니가 눈물 흘리시며 말씀하셨다. 네가 안쓰러워서 여태까지 繼續(계속) 있었어. 이제 잘 지낼 수 있지? 이제 갈게. 나는 꿈 속에서 펑펑 울다 깼다.

이제 내가 좀 괜찮아 졌다는 뜻일까? 어머니가 돌아가신 게 2022年(년) 5月(월) 2日(일)이니, 4年(년) 半(반) 程度(정도) 걸렸구나. 앞으로 꿈에서 살아 계신 어머니를 못 보는 걸까 아쉽다.

Postgres 19 REPACK: Built-In Online Table Bloat Cleanup via @hongminhee https://lobste.rs/s/uutnr5 #databases
https://www.snowflake.com/en/blog/engineering/postgres-19-repack-table-bloat/

@dansup No, @sabrinkmann made it! See also https://hachyderm.io/@sabrinkmann/117540457099069350!

@hongminhee@hollo.social …and part two 📸

Here is your biggest hit of the year.

Sharing very much encouraged! If you share the images yourself, use #FediverseWrapped so others can find them.

@hongminhee@hollo.social here's your Fediverse Wrapped 🎁

365 days, all from your public posts. Times in UTC.

Which tile surprised you?

Sharing very much encouraged! If you share the images yourself, use #FediverseWrapped so others can find them.

Different timezone? Add tz=America/New_York next time.

@fediwrapped_en Could you please wrap my fediverse posts in 2026? Thanks!

It's that time of year again, so I've updated last year's (german) Mastodon Wrapped application to create a new Fediverse Wrapped bot.
If you would like a summary of the last year, simply mention the bot.
Depending on whether you mention the bot publicly or in a private message, you will receive the response.
All you have to do is mention the bot in Toot/Message:
@fediwrapped_en
You can see the result in the quoted message thread. Depending on the load, it takes a few (more) minutes.
The software should work with all Fediverse software versions that have an open Outbox. You can find the code for this here: https://github.com/54GradSoftware/fediverse-wrapped. Thanks to @botkit and @fedify for the technical foundations.

I look forward to receiving feedback and ideas for next year.

Es ist wieder diese Zeit des Jahres, weshalb ich die kleine Mastodon-Wraps-Anwendung vom letzten Jahr in einen neuen Fediverse-Wrapped-Bot umgebaut habe.
Wenn ihr Lust auf eine Zusammenfassung des letzten Jahres habt, könnt ihr den Bot einfach erwähnen.
Je nachdem, ob ihr den Bot öffentlich oder in einer privaten Nachricht erwähnt, erhaltet ihr die Antwort.
Alles, was ihr dafür tun müsst, ist, den Bot zu erwähnen:
@fediwrapped_de
Das Ergebnis seht ihr im zitierten Verlauf. Abhängig von der Auslastung dauert es ein paar (mehr) Minuten.
Die Software sollte mit allen Fediverse-Software-Versionen funktionieren, die eine öffentliche Outbox haben. Den Code dafür gibt es hier: https://github.com/54GradSoftware/fediverse-wrapped Dank @botkit und @fedify für die technischen Grundlagen.

Ich freue mich über Feedback und Ideen für das nächste Jahr.

#FediverseWrapped

ActivityPub.Academy was where many of us checked whether our activities actually arrived anywhere. Thanks @crepels for running it so well for so long.

We're carrying that forward. @z9mb1, @2chanhaeng and I maintain Fedify, and with @gaebalgom the four of us are building @drfed, a web platform for developing and debugging #ActivityPub implementations, with NLnet NGI0 Commons Fund support.

Fediverse developers, we hope it earns a place in your toolkit: https://drfed.org/.

#fedidev

@crepels Thanks for running ActivityPub.Academy all this time. I used it a lot while building Fedify and the other fediverse software I work on: having a real instance to send activities to made federation bugs much easier to track down, and I doubt I'm the only implementer who relied on it. Sorry that spam and the moderation load forced you to shut it down; keeping a public instance usable takes more time than it looks. I hope you find a way to bring it back.

@crepels Activitypub.academy has been invaluable in writing my own project. Thanks for all your effort.

ActivityPub.Academy is plagued by spam accounts posting hateful and illegal content. I hoped that deleting accounts after one day would prevent this, but I was mistaken. Since I don't have the time to moderate the instance, I unfortunately have to take it offline. I will think about ways to provide the academy in some other form. Until then, you can find the source code on https://github.com/sgrj/mastodon.

자유로운, 익명의 인터넷이라는 가치는 낭만의 시대의 기치일 뿐이며 실제로는 유지할 수 없다는 이야기가 나온지도 오래 되었다. 오늘, AI가 모두가 통제된 인터넷을 원하는 세상을 정말로 앞당기고 있을지도 모른다.

모순이라는 말이 있다. 이 맥락에서 단어의 뜻보다 중요한 것은 이 단어의 유래이다. 초나라 때 창은 훌륭한 공격수단이었고 방패는 훌륭한 방어수단이었으며 둘은 서로 겨룰 수 있을 정도로 비교 가능한 것이었다. 오늘날은 그렇지 않다. 기술의 발전은 공격을 방어에 비해 비대칭적으로 예리하게 만든다. 여전히 우리는 방탄복을 입고 콘크리트 벽 뒤에서 시가전을 벌이지만, 그것은 결코 초나라 때의 방패와 성곽만치 든든한 것은 아니다.

2천년이 흘렀다. 초나라 상인에게 방아쇠만 당기면 400보 밖에서 사람을 쓰러뜨릴 수 있는 무기가 있으니 팔아달라고 했더라면, 물건을 팔 때마다 손님이 담벼락 너머로 사라질 때까지 총구가 나를 향하지 않나 지켜보느라 오금이 저릴 것이다. 그러나 우리는 전국에 300만정의 총기가 있는 나라에서 살면서도 어떤 방탄복이 좋은지 고민하지는 않는다. 여러 이유 가운데 하나는 돈뭉치만 싸들고 가면 소총을 팔아주는 상인이 없기 때문이다. 강력한 무기가 나를 겨누지 않고자 한다면 이름표가 붙지 않은 익명의 무기가 있어서는 안된다.

그동안 인터넷의 익명성이 논의와 논쟁의 대상이 되었던 것은 그것이 논쟁거리가 될 정도로 득실을 따질 수 있었기 때문이었다. 우리는 소프트웨어 보안이 합리적인 비용으로 유지 가능한 시대의 마지막을 살고 있을지도 모른다. 인터넷 세계의 창이 날카로워지다 못해 총으로 바뀌게 된다면, 현실적으로 모든 서비스가 방탄일 수는 없다. 보안이 최우선인 거대기업이 운영하지 않는 서비스를 보호할 방법은 보안 강화가 아니라 익명의 총구를 제거하는 것일지도 모른다.

그러므로, 만일 당신이 인터넷이 오늘날과 같기를 바라는 사람 가운데 하나라면, 내일의 인터넷이 '암흑의 숲'이 아니기를 간절히 바라야 할 것이다.

The pull request is merged now: https://w3id.org/fep/f799.

Okay, now it's merged!

https://w3id.org/fep/f799

The Web Can't Afford a JavaScript Runtime Monoculture via @hongminhee https://lobste.rs/s/x6n380 #javascript
https://redmonk.com/kholterhoff/2026/10/27/js-runtime-monoculture/

Following my previous proposal, FEP-22cd: Attributing translations, I've now drafted a proposal for FEP-f799: Coordinated Inbox Delivery Suspension. @nyanrus also helped out this time! The PR hasn't been merged yet, but you can read it here in the meantime.

@jackalope_tracks 알려주신 링크가 https://jpendleton.substack.com/about 쪽으로 리다이렉트되는 것 같은데, 이 링크가 맞나요? 아티클(article)이 아니라 作家(작가) 紹介(소개) 페이지 같아서요!

AI ban should not be an excuse to exclude minorities, as I heard some communities started banning non English speakers who use machine translation

이 짤이 벌써 10年(년)도 넘었구나. 좋아하는 블랙 조크지만 韓國語(한국어) 話者(화자)가 아니면 웃긴 포인트들을 제대로 알아채기 힘들 듯…? 😂 프로필 寫眞(사진)과 닉네임이 伊藤博文(이토 히로부미)인 點(점)(게다가 日本語(일본어) 읽기가 아니라 韓國語(한국어) 漢字音(한자음) 읽기인 「이등박문」)이나, 朴正熙(박정희)를 굳이 그의 創氏改名(창씨개명)한 日(일)本姓(본성)인 「高木(고목)」로 부른 點(점)이나, 「內地(내지)」라는 表現(표현)이 韓國語(한국어)에서 갖는 뉘앙스라든가…

參考(참고)로, 伊藤博文(이토 히로부미)와 朴正熙(박정희) 둘 다 射殺(사살)된 날이 10月(월) 26日(일)로 같다. (伊藤博文(이토 히로부미)은 1909年(년) 10月(월) 26日(일), 朴正熙(박정희)는 1979年(년) 10月(월) 26日(일).)

Hollo security updates: 0.8.17 and 0.9.25

If you run Hollo, update to 0.8.17 or 0.9.25 now. These releases fix GHSA-r48c-xx2h-fv4g, a DNS rebinding vulnerability in Fedify that could bypass Hollo's server-side request forgery (SSRF) protection and cause requests to reach internal services.

Fedify checked that a hostname resolved only to public addresses, then let the HTTP client resolve it again when connecting. An attacker controlling the hostname's DNS answers could return a public address for validation and a private or loopback address for the connection. Redirects and alternate-document links had the same gap.

The affected Fedify paths used by Hollo include remote document loading (authenticated or not), outbound activity delivery, and WebFinger lookups. On Node.js, which Hollo uses, the fix restricts connections to addresses that passed validation. Hollo's ALLOW_PRIVATE_ADDRESS=true option still permits private destinations; leave it unset for public federation. For full technical details, see the Fedify security announcement and the advisory linked above.

All releases on the supported Hollo 0.8.x and 0.9.x lines up to and including 0.8.16 and 0.9.24 are affected. 0.8.17 and 0.9.25 are the first fixed releases and the latest on those lines, incorporating Fedify 2.1.31 and 2.2.20 respectively. Hollo 0.7.x and earlier are no longer supported under the Hollo security policy; operators on those lines should move to a supported release.

For 0.8.x deployments, update to 0.8.17:

docker pull ghcr.io/fedify-dev/hollo:0.8.17

For 0.9.x deployments, update to 0.9.25:

docker pull ghcr.io/fedify-dev/hollo:0.9.25

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 using the pnpm version pinned in that tag's package.json, 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 the new version's automatic migration.

Thanks to @finalchild for reporting the DNS rebinding issue to the Fedify project.

If anything is unclear, ask below.

If you use BotKit, update to a patched release now. GHSA-r48c-xx2h-fv4g is a DNS rebinding vulnerability in Fedify, which BotKit uses for federation. An attacker could bypass its server-side request forgery (SSRF) protection and cause your bot's server to reach internal services. Deno deployments need additional network restrictions; upgrading BotKit alone does not close the vulnerability on Deno.

Fedify checked that a hostname resolved only to public addresses, then let fetch() resolve it again when connecting. An attacker controlling the hostname's DNS answers could return a public address for validation and a private or loopback address for the connection. This affects remote document loading, both anonymous and authenticated, as well as outbound activity delivery, NodeInfo lookups, and WebFinger lookups. Redirects and alternate-document links were subject to the same gap.

On Node.js and Bun, the fix makes connections only to addresses that passed validation. Bun deployments that set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, including their lowercase forms, should use Bun 1.4.3 or later. Alternatively, unset those variables for the bot process or configure the proxy to refuse private destinations. Earlier Bun versions can send requests through a proxy that resolves the hostname again. With the fix applied, HTTPS requests to non-default ports fail on Bun versions before 1.3.11 because those versions cannot verify a pinned connection's certificate against the original hostname. See the Bun deployment guidance.

Deno's fetch() cannot pin connections to validated addresses. Use Deno 2.8.1 or later with the documented --deny-net list covering private IPv4 ranges, [::1], and [::], and listen on a Unix domain socket behind a reverse proxy, since the deny list also blocks listening on those IP addresses. Private IPv6 ranges also need network-level restrictions. If that setup is unsuitable, apply equivalent outbound restrictions at the firewall or container network layer. Follow the Deno deployment mitigation for the full deny list and deployment requirements.

BotKit 0.4.x versions through 0.4.10 and BotKit 0.5.x versions through 0.5.7 include affected Fedify versions. The first releases containing the fix, and the current recommended releases, are BotKit 0.4.11 and 0.5.8, which upgrade Fedify to 2.1.31 and 2.3.15, respectively. These are the two supported BotKit lines under the security policy; users on older lines should move to a supported release.

For BotKit 0.5.x, install @fedify/botkit 0.5.8 using the command for your package manager:

npm  install @fedify/botkit@0.5.8
yarn add     @fedify/botkit@0.5.8
pnpm add     @fedify/botkit@0.5.8
bun  add     @fedify/botkit@0.5.8
deno add     jsr:@fedify/botkit@0.5.8

For BotKit 0.4.x, install @fedify/botkit 0.4.11:

npm  install @fedify/botkit@0.4.11
yarn add     @fedify/botkit@0.4.11
pnpm add     @fedify/botkit@0.4.11
bun  add     @fedify/botkit@0.4.11
deno add     jsr:@fedify/botkit@0.4.11

Check the installed or locked versions: @fedify/botkit should be 0.4.11 or 0.5.8. The affected Fedify packages, @fedify/fedify, @fedify/vocab-runtime, and @fedify/webfinger, should resolve to at least 2.1.31 on the 2.1.x line, 2.2.20 on 2.2.x, 2.3.15 on 2.3.x, or 2.4.5 on 2.4.x. Update any direct dependencies on those packages too. If you use a routine update command instead, check that your declared dependency range allows a patched release and change it explicitly if needed. Apply the runtime mitigations above and redeploy all web and worker processes.

The full GitHub Security Advisory is GHSA-r48c-xx2h-fv4g. See also Fedify's own announcement.

Thanks to @finalchild for reporting the DNS rebinding issue to the Fedify project.

If anything is unclear, feel free to ask on GitHub Discussions or Matrix.

A security update addressing two vulnerabilities in Fedify has been released. Please update as soon as possible!

https://hackers.pub/@fedify/2026/GHSA-r48c-xx2h-fv4g

If you use an affected Fedify release, update now. Two server-side request forgery vulnerabilities have been addressed: GHSA-r48c-xx2h-fv4g, a DNS rebinding bypass of Fedify's private address checks, and GHSA-cj5r-cw77-6gwp, unvalidated page and favicon requests in fedify nodeinfo. Deno deployments need additional network restrictions; upgrading Fedify alone does not close the DNS rebinding vulnerability.

The patched releases are 2.0.35, 2.1.31, 2.2.20, 2.3.15, and 2.4.5. Update to the corresponding release on your minor line, with the runtime mitigations described below. The affected releases on these lines are 2.0.34 and earlier, 2.1.30 and earlier, 2.2.19 and earlier, 2.3.14 and earlier, and 2.4.4 and earlier. For ongoing support, the security policy covers the latest two minor lines, 2.3 and 2.4. Users on releases before 2.0 should move to a supported release.

DNS rebinding bypasses SSRF protection (GHSA-r48c-xx2h-fv4g, medium, CVSS 5.4)

Fedify checked that a hostname resolved only to public addresses, then let fetch() resolve it again when connecting. An attacker controlling the hostname's DNS answers could return a public address for validation and a private or loopback address for the connection, causing requests to reach internal services. Redirects and alternate-document links were subject to the same gap.

This affects document loading, including authenticated document loading, outbound activity delivery, NodeInfo lookups, and WebFinger lookups in @fedify/fedify, @fedify/vocab-runtime, and @fedify/webfinger. On Node.js and Bun, the fix makes connections only to addresses that passed validation. Calling validatePublicUrl() before an application's own fetch() still does not pin that connection. Setting allowPrivateAddress: true continues to permit private destinations.

On Bun, deployments with HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY set, including their lowercase forms, should upgrade to Bun 1.4.3 or later. Alternatively, unset those variables for the Fedify process or configure the proxy to refuse private destinations. Older Bun versions may send requests through a proxy that resolves the hostname again. On Bun versions before 1.3.11, Fedify now refuses HTTPS requests to non-default ports because those Bun versions cannot verify a pinned connection's certificate against the original hostname. See the Bun deployment guidance.

Deno's fetch() cannot pin connections to validated addresses. Use Deno 2.8.1 or later with the documented --deny-net list and a Unix domain socket behind a reverse proxy, plus network-level restrictions for private IPv6 ranges. If that setup is unsuitable, apply equivalent outbound restrictions at the firewall or container network layer. Follow the Deno deployment mitigation.

Unvalidated page and favicon requests (GHSA-cj5r-cw77-6gwp, low, CVSS 3.1)

An operator running fedify nodeinfo against a malicious instance could cause the CLI to send a GET request to a loopback, link-local, or private address from the operator's machine. The NodeInfo lookup validated destinations, but the subsequent page and favicon requests used plain fetch() with automatic redirects. A malicious favicon URL or page redirect could therefore reach an internal endpoint.

The attacker does not directly receive the response body, but the request can affect an internal endpoint with GET side effects. The fix validates page, favicon, and redirect destinations, skipping the favicon when a destination is private while still showing the NodeInfo document. Upgrade @fedify/cli separately from the library. Until then, --no-favicon or --raw avoids these page and favicon requests. The Bun and Deno caveats above also apply to the CLI.

Updating

Use the command for your package manager to install 2.4.5 explicitly:

npm  install @fedify/fedify@2.4.5
yarn add     @fedify/fedify@2.4.5
pnpm add     @fedify/fedify@2.4.5
bun  add     @fedify/fedify@2.4.5
deno add jsr:@fedify/fedify@2.4.5

If you stay on another minor line, substitute 2.0.35, 2.1.31, 2.2.20, or 2.3.15 as appropriate. Update direct dependencies on @fedify/vocab-runtime and @fedify/webfinger to the same release as well. Check the resolved versions in your lockfile, since an ordinary update command can stay within a vulnerable dependency range or leave a transitive dependency locked. Apply the runtime mitigations above and redeploy all web and worker processes.

For an npm-installed global CLI:

npm install -g @fedify/cli@2.4.5

For other installation methods, reinstall the corresponding patched version using the CLI installation instructions. Check fedify --version before using it against an untrusted instance.

Thanks to @finalchild for reporting the DNS rebinding issue and to Zachariah Mithani for reporting the favicon request issue.

If anything is unclear, ask below.

올해 11月(월) 末(말) 서울에서 開催(개최)되는 @fossforall Conference 2026에서 〈Oseo: SBCL 스타일의 JavaScript/TypeScript AOT 컴파일러〉라는 題目(제목)으로 發表(발표)합니다. Oseo는 JavaScript/TypeScript를 인터프리터나 JIT 없이 미리 네이티브 코드로 컴파일하는 프로젝트로, 動的(동적) 타입 言語(언어)임에도 오래 前(전)부터 AOT 컴파일러가 쓰여 온 SBCL이나 Chez Scheme 같은 Common Lisp 및 Scheme 系譜(계보)에서 靈感(영감)을 얻었습니다. 모든 函數(함수)를 저네릭(generic) 經路(경로)와 가드가 붙은 特殊化(특수화) 經路(경로)로 두 벌 컴파일해 두고, 가드가 失敗(실패)하면 바이너리 안의 저네릭 經路(경로)로 갈라질 뿐 最適化(최적화) 解除(해제)(deoptimization) 같은 건 하지 않는 게 核心(핵심) 아이디어입니다.

아직 未完成(미완성)인 프로젝트라, 實際로(실제로) 돌아가는 모습과 앞으로 남은 길을 함께 보여드릴 豫定(예정)입니다. 寄與(기여)에 關心(관심) 있는 분도 歡迎(환영)합니다.

Really excited to see progress on this effort after many many years of stalled discussion. Thanks to @Edent, @hongminhee, @lnkr, @north and @evan as well for their recent work on this matter, I can now see a fediverse in sight that supports the world's languages fully!