Yuriha
Yuriha
## Summary 配送ジョブにおける署名処理が重いので、暗号鍵の方式を変更して軽くしたい。 ## Details Misskeyの鍵長がRSA4096bitと、MastodonのRSA2048bitとくらべセキュリティの高い設定になっているため、連合におけるノートの配送のボトルネックとなっている署名処理の計算コストが（7倍程度）大きい。 RSA2048bitで妥協するか、ECDSAやEdDSAなどの安全性を保ちつつ効率の良い署名アルゴリズムを使うことで、計算の負荷を減少させることができる。ECDSAやEdDSAを使うことにする場合、既存のサーバーは対応していないので、ユーザーの鍵はRSAとECDSAの保存しておいて、連合先サーバーとのネゴシエーションによって、渡す公開鍵を決める必要があると思われる。 参考までに各アルゴリズムのOpenSSLによる速度測定例を置いておきます。 (AMD EPYC 7B12: 1CPU当たりの性能) - RSA 2048bit - 署名:1517.4/s - 検証:52966.6/s - RSA 4096bit: - 署名: 220.6/s - 検証:14481.2/s - ECDSA 256bit...
## What Fixes #11000 インスタンスの情報のDB上の最終更新時刻を確認し、古かったら更新する操作がredis-lockにより排他制御されていたが、ロックを取得できなかった場合にリトライするのをやめ、何もしないようにした。 ## Why FetchInstanceMetadata は Deliver Jobから呼ばれるため高速大量に呼ばれるため、これを改めることでパフォーマンスが顕著に改善する。 このロックはインスタンス情報の更新操作が一回だけ行われることを目的としているため、ロックが取得できない場合、何もしないことに問題はない。 ## Additional info (optional) 以下の動作を確認しました。 - Deliver完了時にInstance Metadataが正しく更新されることを確認した。 - 大量のDeliverを高速に行ったときに、パフォーマンスが改善することを確認した。 redis-lockにリトライを設定するオプションがなかったので、Redis上にロックとして使うキーを設定し、これをアトミックに参照・書き換える実装とした。 ## Checklist - [x] Read the [contribution...
## What ユーザーが投稿できるメンションとダイレクト投稿の宛先の数をロールごとに制限する。リモートの投稿も対象となる。 ## Why メンションを多数つけた投稿を行うことで、スパムを投稿しようとする攻撃者は、限られたレートリミットにおいてスパムの送付対象となる被害ユーザーを増やすことができる。そのため、一つのノートにつけられるメンションの数を制限することで、スパムを送付する効率を下げることができると考えられる。 ロールごとにメンションとダイレクト投稿の宛先の数を制限することにより、信頼のおけるユーザーのみが複数のメンションを許すというサーバーの運用が可能になる。 ## Additional info (optional) ## Checklist - [x] Read the [contribution guide](https://github.com/misskey-dev/misskey/blob/develop/CONTRIBUTING.md) - [x] Test working in a local environment - [ ]...