mei23 / misskey Goto Github PK

This project forked from misskey-dev/misskey

めいすきー

License: GNU Affero General Public License v3.0

TypeScript 53.18% CSS 0.02% Vue 45.05% JavaScript 0.92% Dockerfile 0.02% Perl 0.02% Stylus 0.47% Pug 0.32% Shell 0.01% Procfile 0.01%

misskey's Introduction

めいすきー (Meisskey)

Meisskey is a decentralized microblogging platform.
The fork of Misskey

Setup?

簡単なセットアップ方法はこの辺
https://github.com/mei23/memo/blob/master/misskey/Setup-Meisskey-Quick.md

Vulnerabilities?

脆弱性を見つけたらこちら
If you find any vulnerabilities, please report them here.
https://github.com/mei23/misskey/security/advisories/new

misskey's People

Contributors

Stargazers

Watchers

Forkers

clarinet758 coke12103 leies-202 sousuke0422 yumehaki atsu1125 t-asa2000 kemomimisskey-dev aris-mirai takusan23 izuruyakumo

misskey's Issues

preventCacheRemoteFiles: true の時にリモートアイコンが表示できなくなる

Summary

preventCacheRemoteFiles: true の時に、Mastodonで A=>B=>A のようにアイコンを変更するとアイコンが（そのうち）表示できなくなる。

Expected Behavior

表示できる

Actual Behavior

できない

Steps to Reproduce

以下の条件を満たしていると事象がわかりやすい

Mastodon側の画像サーバーにはキャッシュやCDNを使用してない状態
ブラウザのキャッシュは無効にしておく
使用するファイルはアニメーションGIF

Misskey側では、preventCacheRemoteFiles: true にしておく
Mastodonの特定ユーザーをMisskeyからフォローしておく
Mastodonの特定ユーザーで、画像1をアイコンに設定する
Mastodonの特定ユーザーで、画像2をアイコンに設定する
Mastodonの特定ユーザーで、画像1を再度アイコンに設定する
→Misskey側でMastodon側の画像を参照した際に404になる

Environment

Mastodonで hash=x001の画像を001.gifで保存し、それをアイコンとする。
Misskeyはそれを[hash=x001, url=001.gif]として記録して、リンクして使用する。
↓
Mastodonが hash=x002の画像を 002.gifで保存し、それをアイコンとする。この時点で001.gifは削除される。
Misskeyはそれを[hash=x002, url=002.gif]として記録して、リンクして使用する。
↓
Mastodonが hash=x001の画像を 003.gifで保存し、それをアイコンとする。
Misskeyは hashが2のものと同じため [hash=x001, url=001.gif] のままurlは変えないままになる。
↓
001.gif もはや削除されているため表示できない。

なお、preventCacheRemoteFiles: false に後で変更しても、
同ハッシュのurlは更新されないのでなおらない。

Summary

特定のダミーユーザー(ここではvipPublicとする)をフォローされると、
vipPublicをフォローしている人がいる他インスタンスのグローバルTL向けに、
このインスタンスの全てのPublic投稿を配信してあげる機能。

Description

連合拡張したい→このインスタンスのPublic投稿全部欲しいという要望に対応。

今までは、全フォローbot回したり、大量のフォローリストインポートするしかありませんでした。

全フォローbot回すのは、リソースを消費します。
また、性質上本来連合に乗らないフォロワー限定/ホーム限定(未収載)投稿も取得してしまうため
フォローされた被取得ユーザーは警戒してしまいますし、フォロワー限定投稿が常に取得されることに不快感を抱く可能性があります。
送受信を行うインスタンスから見ても、連合に乗らないPublic以外の投稿を無駄に送受信することになります。

フォローリストインポートは、準備する必要がありますし、これがかなりのリソースを消費します。

pub-relayなどもありますが、被フォローされるインスタンスの管理者が何もしないと意味がありません。（これそもそも連合拡張を目的とした機能？）

そこで、Public投稿のみを配信する機能を設けます。
既存のフォローとSharedInbox配信の仕組みを使用しますので、配信される側のインスタンスでは特に変更をする必要はありません。

Summary

Environment

Summary

Expected Behavior

Actual Behavior

Steps to Reproduce

Environment

HTTP Signature の署名対象ヘッダが少ない

ActivityPubリクエスト時にHTTP Signatureを付加しているけど
署名対象ヘッダがdateだけなので他の部分は改竄して再利用できちゃいそう。

他の実装は、特に Request body の Digest を取って
Digest: SHA-256=WlctSMTBmlBaS38jiiLh2iE2WpPYBebwLa+6WG2AKOI= みたいなの
それを検証対象ヘッダに含めてそうだわ。

実装	署名対象ヘッダ
Mastodon	(request-target) user-agent host date accept-encoding digest
Pleroma	content-length digest host

投稿する度にMastodonからAP person/publickey取得がいっぱいくる

Summary

Misskeyで投稿する度にMastodonから以下のURLへリクエストが飛んでくる

"GET /users/xxxxxxxxxxxxxxxxxxxxxxxx/publickey HTTP/1.1" 200 708 "-" "http.rb/3.2.0 (Mastodon/2.5.0; +https://mastodon.example.com/)"
"GET /users/xxxxxxxxxxxxxxxxxxxxxxxx/publickey HTTP/1.1" 200 708 "-" "http.rb/3.2.0 (Mastodon/2.5.0; +https://mastodon.example.com/)"
"GET /users/xxxxxxxxxxxxxxxxxxxxxxxx HTTP/1.1" 200 726 "-" "http.rb/3.2.0 (Mastodon/2.5.0; +https://mastodon.example.com/)"

Mastodon 1インスタンスの1フォロワーにつき
上の(publickey x 2 + user x1 = 3)個のリクエストが投稿する度に毎回飛んでくる

Mastodonインスタンス内のフォロワーが増えるに従ってリクエスト数も増える

以下のパターンで起きる

Misskey→Mastodon に配信

以下のパターンでは起きない

Misskey→Misskey に配信
Mastodon→Mastodon に配信
Mastodon→Misskey に配信

相手のMastodonは、2.5.0 でも 1.6.1 でも確認

署名照合とかそのへん？
Linked Data Signatures が付いてないとくるとか？

publickeyのURLの振り方の違いが影響？

person:    https://mastodon.example.com/users/xxxxx
publickey: https://mastodon.example.com/users/xxxxx#main-key

person:    https://misskey.example.com/users/xxxxx
publickey: https://misskey.example.com/users/xxxxx/publickey

MastodonはpersonとかにCache-Control: max-age=180, publicついてる

ActivityPub Followers/Following/Outbox をページングできるように実装する

Mastodon 2.4 ライク？

Followers/Following/Outbox
https://www.w3.org/TR/activitypub/#followers
https://www.w3.org/TR/activitypub/#following
https://www.w3.org/TR/activitypub/#outbox

ページング
https://www.w3.org/TR/activitystreams-core/#paging

Summary

メディアを常に閲覧注意としてマークする
閲覧注意としてマークされたメディアも常に表示する

Environment

Summary

主にWebSocketとかの接続数を取得したい

Nodeにはあるみたいだけど、1 Worker Process分だろうし、Keep-Aliveもあるのでダメな気がする。
https://nodejs.org/api/net.html#net_server_getconnections_callback

Nginx stub_status の Writing がほぼWebSocketの接続数になってそう。
http://nginx.org/en/docs/http/ngx_http_stub_status_module.html

Active connections: 210
server accepts handled requests
 110164 110164 200029
Reading: 0 Writing: 38 Waiting: 172

Environment

Summary

Expected Behavior

Actual Behavior

Steps to Reproduce

Environment

Summary

Expected Behavior

Actual Behavior

Steps to Reproduce

Environment

Activity idのURLでActivityの内容が参照できる機能

Summary

ActivityPubで
Mastodon の CreateNote/Announce Activity 内の
/activityを含むURLを参照すると、該当Activityと同じ内容が参照できるようです。
（Noteの内容が参照できるURLとは違い、Activityでwrapされている）

@context: 
id: "https://example.com/users/USER/statuses/ID/activity" ←このURLで同じ内容が参照できる
type: "Create"
object: {
  id: "https://example.com/users/USER/statuses/ID"
  type: "Note"
}

@context: 
id: "https://example.com/users/USER/statuses/ID/activity" ←このURLで同じ内容が参照できる
type: "Announce"
object: "https://example.com/users/USER/statuses/ID2"

特に必須というわけではないが、Outboxの副産物でできるのと、
デバッグに便利だったりするので実装したい。

参照を許可するNoteは、PublicとHomeを対象にする。
（Mastodonは認証(セッションCookie使用？)次第では、フォロワー限定やプライベート投稿も参照できるようだが、対応しない）

Environment

Summary

Expected Behavior

Actual Behavior

Steps to Reproduce

Environment

Summary

Environment

Summary

リモートフォローする際、（鍵アカウントと認識していない限り）
常に成功する前提でステータスを変更しているため、おかしくなることがある

1. 相手をローカルでは非鍵と認識しているが、実際は鍵アカウントの場合
（ローカルキャッシュ情報が古い場合など）
Expected: ローカル=承認待ち , リモート=承認待ち
Actual: ローカル=フォロー済み, リモート=承認待ち

2. 相手にブロックされている場合
Expected: ローカル=未フォローに戻される
Actual: ローカル=フォロー済みになる

3. インスタンスが存在しない/通信エラー等
Expected: ローカル=承認待ちになる
Actual: ローカル=フォロー済みになる

Steps to Reproduce

Summaryの1: 非鍵のリモートアカウントを参照した後に、リモート側で鍵に変更する、そのリモートアカウントをフォロー

Summaryの2: ブロックされているリモートアカウントをフォロー

Environment

Summary

タイムラインで日付が変わった際に日付区切りのバーが挿入されるが、
ローカル, ローカルユーザー以外TLの(連合が絡むTL)では表示しないようにする。

ローカル, ローカルユーザー以外のTLでは、
連合から過去の投稿が到着(Renote/Replyなどにより)することがあり
その度に日付切り換えが表示されてしまうため。

Environment

Summary

Environment

Summary

ActivityPub Outbox において
現状OrderedCollectionPage/orderedItemsがObject(Note)のリストになっていますが

@context: 
type: "OrderedCollectionPage"
orderedItems: [
  { type: "Note" }
  { type: "Note" }
]

↓
正しくはActivity(Create/Announce など)のリストのようです。

@context: 
type: "OrderedCollectionPage"
[
  { type: "Create", object: { type: "Note" } }
  { type: "Create", object: { type: "Note" } }
  { type: "Announce", object: "https://example.com/..." }
]

なお、ActivityなのでAnnounce(Renote)も含むのではと思われる。

https://www.w3.org/TR/activitypub/#outbox や Mastodonの実装を参照しました。

Environment

CloudFlareはURLに指定拡張子が付いてないとキャッシュしてくれないので配慮する

Summary

https://support.cloudflare.com/hc/en-us/articles/200172516-What-file-extensions-does-CloudFlare-cache-for-static-content-

Environment

ActivityのactorにObjectを指定されると検証手段がない

Activityのactorのように、PersonのURIが指定されてくる場所では
PersonのObject自体が添付されることも許容しているが
この場合、内容が正当なホストのものか検証する手段がない。

HTTP Signature があるが、検証前に公開鍵を設定出来てしまうので意味なさそう。

Activity受信時に、activity.actor にURIでなくてオブジェクトを指定されると
相手の名乗った情報(公開鍵を含む)を、そのまま登録できてしまう。
https://github.com/syuilo/misskey/blob/09f97bf7a7e0652fe7438e13164586ef4431cba6/src/queue/processors/http/process-inbox.ts#L37-L40
https://github.com/syuilo/misskey/blob/09f97bf7a7e0652fe7438e13164586ef4431cba6/src/queue/processors/http/process-inbox.ts#L47-L50

その後署名検証がその登録された鍵で行われる可能性がある
https://github.com/syuilo/misskey/blob/09f97bf7a7e0652fe7438e13164586ef4431cba6/src/queue/processors/http/process-inbox.ts#L58-L62

Summary

Expected Behavior

Actual Behavior

Steps to Reproduce

Environment

Summary

引用 && 本文なし && メディア添付がただのRenoteになる
引用 && 本文なし && アンケートがただのRenoteになる

Expected Behavior

Actual Behavior

Steps to Reproduce

Environment

Summary

Environment

AP Note-Reply/Announce等に対象を添付するときにSignatureや公開範囲はどうなのか

公開範囲関係なく添付してそう
他人の投稿を添付する/が添付されている場合、署名がされてないので信用ができない。
（偽装できそう）

Summary

Environment

リモートからメンションっぽいテキストが流れてきた時にローカル向けと誤認される

Summary

リモートから@foo形式のテキスト(メンションではない)が流れてきた時にローカル向けのメンションになってしまう

Expected Behavior

Actual Behavior

Steps to Reproduce

Environment

Summary

Environment

Summary

Expected Behavior

Actual Behavior

Steps to Reproduce

Environment

Summary

Environment

Summary

Environment

ActivityPub公開範囲でおかしいところ

Misskey発の Public/Home/Follower/Directが他インスタンス(Mastodon/Misskey問わず)にはPublicで届く
→未実装だったはず…
Follower宛て投稿が届かない(メンションありなし問わず)

Error: invalid person: object is not a person or service 'OrderedCollection'
    at validatePerson (/home/xxx/misskey/built/remote/activitypub/models/person.ts:23:10)
    at createPerson (/home/xxx/misskey/built/remote/activitypub/models/person.ts:78:14)
    at process._tickCallback (internal/process/next_tick.js:68:7)

DM(Direcy + メンション)がFollowerで届く
3.1. Streamingでは「この投稿は非公開です」と出てしまう

Summary

Environment

Summary

Environment

AP Request に付けたほうがよさそうなの

HTTP / Content-Type: application/activity+json
HTTP / User-Agent:
Activity / id
Activity / actor (allways)

Summary

Environment

APでPersonを取得した際、取得内容のホスト名部分が取得対象URIのホストだったか検証してない。
このため、別のインスタンスを騙ってリモートユーザーを登録できてしまいそう。
https://github.com/syuilo/misskey/blob/09f97bf7a7e0652fe7438e13164586ef4431cba6/src/remote/activitypub/models/person.ts#L74