しかしこれ、Activity Streamsとしては妥当でもActivityPubとしては副作用を伴う操作を通知するための`inbox`を特定できないのが困るか。
うーん、`endpoints`プロパティは任意のオブジェクトに持たせても良いものとしません？（？）
しかしこれ、Activity Streamsとしては妥当でもActivityPubとしては副作用を伴う操作を通知するための`inbox`を特定できないのが困るか。
うーん、`endpoints`プロパティは任意のオブジェクトに持たせても良いものとしません？（？）
規格上はそうなのだが、現実に拡張データはすべて (署名まわりのあれこれとかもたぶん含めて) JSON-LD セマンティクスで付与されるので、そこに問題がある
つまり吐く方は特定の構造を決め打ちで吐くのでも良いのだが、読む方が JSON-LD 非対応で特定の構造のみに対応してしまうと、「本当は嘘の署名があるのに、署名がないと認識して素通ししてしまう」みたいなアカン現象を発生させるおそれがあるのでセキュリティリスクになる
https://nvd.nist.gov/vuln/detail/CVE-2022-24307
> Mastodon before 3.3.2 and 3.4.x before 3.4.6 has incorrect access control because it does not compact incoming signed JSON-LD activities. (JSON-LD signing has been supported since version 1.6.0.)
まあ基本的に送信側としては利用する全てのタームを`@context`で定義しておけば十分で（これはそこまで難しくない）、受信側としてはRDFベースの署名を無視する方針なら特にセキュリティ上の問題はないはず。
オブジェクトの署名を無視しても一応`id`のURIをfetchすればオブジェクトの真正性は検証できるし（非効率だけど）。Pleromaとかがinbox forwardingをそのように処理しているという話を聞いた覚えがある
Add tests for CVE-2022-24307 by ClearlyClaire · Pull Request #17733 · mastodon/mastodon
https://github.com/mastodon/mastodon/pull/17733
テストケースに攻撃の具体例がある
具体的なJSONシリアリゼーションでなくRDFデータセットを署名することで、例えばJSON-LDで送られてきたオブジェクトを署名を保ったままCBOR-LDに変換できちまうんだ。すごい！ 実際にそんなことをしている実装があるのかは知らんけど！
まあ、Mastodonのドキュメント（<https://docs.joinmastodon.org/spec/security/#ld>）にも書かれているとおり、Linked Data Signaturesというドラフト段階の仕様は必要がないなら実装するべきでないですよね（今言うことか？）
どうしてもRDFデータセットを署名したいならVerifiable Credentials Data Integrityが勧告になるのを待って`eddsa-rdfc-2022` cryptosuiteあたりを使うのが理想的なやり方かな。
まあFEP-8b32 (Object Integrity Proofs)ではJSONベースの`eddsa-jcs-2022`が推奨されているのだけど
FEP-8b32はJSONベースの署名を埋め込みオブジェクトで上手く動作させるために`object`タームの定義をオーバーライドしてセマンティクスにも手を入れているけど（<https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#nested-objects>）、Activity StreamsオブジェクトをRDFとして扱っている実装（`rdf-pub`がそうだっけ？）との互換性が気になっている
@hongminhee フォーク元のMastodonのバージョンが編集機能が実装されるより以前のものだったらしいです
QT: https://fedibird.com/@noellabo/110802815074446074 [参照]
RUSTSEC-2024-0370: proc-macro-error: proc-macro-error is unmaintained › RustSec Advisory Database
https://rustsec.org/advisories/RUSTSEC-2024-0370.html
セキュリティ的な問題はあまりなさそうだけど、`syn` v2対応の見込みがないのは確かに困るな
まあ私の場合は元々自前のユーティリティがあって、それをほぼdrop-inで`proc-macro-error`に置き換えただけなので、最悪それを元に戻すだけで済みそうだけど
Use `proc-macro-error` crate · tesaguri/oauth1-request-rs@c03480f
https://github.com/tesaguri/oauth1-request-rs/commit/c03480f5af5bc235e01c9f0404f3c513ab9b620a
55 additions and 88 deletionsか。まあコード量としては許容範囲か。
`proc-macro-crate`の"dummy implementations"機能にも新たに依存しているけど、これは普通に自前で同様のことが出来そうかな
正直`proc_macro_error`属性マクロが具体的に何をしているのかよく把握していなかったので、処理が明示的だったという点でむしろ自前APIの方が良かったまであるかもしれない
Don't leak a TokenStream in Ctxt::emit_errors. by eddyb · Pull Request #2 · tesaguri/oauth1-request-rs
https://github.com/tesaguri/oauth1-request-rs/pull/2
（空の）`TokenStream`を`forget`するという操作でCraterに引っかかった思い出
https://github.com/tesaguri/oauth1-request-rs/blob/2a9ff26f05baba9ec7f2075d77d3a67189bbbff1/oauth1-request-derive/src/method_body/helper.rs#L93-L94
コンパイルテストの意図であえて`&String::new()`としていたのがClippyで`""`にするように警告されるな（それはそう）
誤操作でFirefoxの`permissions.sqlite`を消してしまった……
`Profiles`ディレクトリの外で`sqlite3 permissions.sqlite`して間違ったわガハハと言いながら`rm permissions.sqlite`しつつ`Profiles`ディレクトリに`pushd`して、そこで`^Rperm^J`してしまい、はい
まあ消したのが`storage.sqlite`などでなく`permissions.sqlite`だったのは不幸中の幸いか。設定を元に戻すのが面倒くさいけど……
`myna.go.jp`とかいう、Cookieを拒否するだけで無限リダイレクトするWebサイトなあ……
@silverpill Ah, that's good to know! Thank you!