リダイレクトを含むユーザの照会がエラーになる

[anatawa12]

💡 Summary

https://mi.7mi.site/@[email protected] のようなURLで照会すると (つまりリダイレクトを含む照会をすると) 2024.10.1のサーバーでは問題なく照会できるのに 2024.11.0 のサーバーだと 500 internal server error を返します。

複数のサーバーで確認しました。

🥰 Expected Behavior

リダイレクトをちゃんと追跡して照会できる

🤬 Actual Behavior

500 internal server errorが返ってくる

📝 Steps to Reproduce

1. 適当な 2024.11.0 以降の misskey または他の (ほかサーバーの投稿を activity pub としてリクエストした際に本家のサーバーにリダイレクトする) activity pub 実装 のサーバーで、そのサーバー以外のユーザのページを開いてその URL をコピーする
2. 2024.11.0 のサーバーで1で取得した URL で照会を行う

💻 Frontend Environment

* Model and OS of the device(s):
* Browser:
* Server URL:
* Misskey:

🛰 Backend Environment (for server admin)

* Installation Method or Hosting Service: docker + k8s
* Misskey: 2024.11.0-kinel.1
* Node: ??
* PostgreSQL: ?? 
* Redis: ?? 
* OS and Architecture: Linux ??

Do you want to address this bug yourself?

• Yes, I will patch the bug myself and send a pull request

[eternal-flame-AD]

The fetched host is already guaranteed to be from the authoritative source (assertActivityMatchesUrls) here:

取得されたホストは、すでに信頼できるソース (assertActivityMatchesUrls) からのものであることが保証されています：

misskey/packages/backend/src/core/activitypub/ApResolverService.ts

Lines 109 to 111 in 8076f78

	const object = (this.user
	? await this.apRequestService.signedGet(value, this.user) as IObject
	: await this.httpRequestService.getActivityJson(value)) as IObject;

I do not think we have to check again without considering redirects (as the returned object will have the correct attribution and this original host has no control over it) the most mi.7mi.site can do is redirect you to a different site, but the returned user will have to match that different domain to pass the above check which will be clearly identifiable by the user:

リダイレクトを考慮せずに再度確認する必要はないと思います (返されるオブジェクトには正しい属性があり、元のホスト（mi.7mi.site）は制御できない) できることはせいぜい別のホストにリダイレクトすることですが、返されるホストはmisskey.ioではないのははっきりと表示されます。

misskey/packages/backend/src/core/activitypub/ApResolverService.ts

Lines 129 to 131 in 8076f78

	if (this.utilityService.punyHost(object.id) !== this.utilityService.punyHost(value)) {
	throw new Error(`invalid AP object ${value}: id ${object.id} has different host`);
	}

However it is impossible to be sure without an appropriate advisory clearly identifying the reasoning of multiple seemingly-redundant checks like these. I hope the advisory can be published so instance owners know the how to appropriately deal with these patches (which are already public), as opposed to being tempted to revert them potentially exposing them to known threats.

ただし、このような複数のチェックの理由を明確に示す適切なアドバイスがなければ、確信を得ることはできません。インスタンス所有者がこれらのパッチ (すでに公開されています) を適切に処理する方法を知ることができるように、アドバイスが公開されることを願っています。

[eternal-flame-AD]

リダイレクトを許可することによるリスクはユーザーが確認していないことですが（？）、それはバックエンドのエラーではなく、フロントエンドの警告のほうが良いと思います。