Question 1

bytesクレートにおける整数オーバーフローの脆弱性 (RUSTSEC-2026-0007) を修正する方法は？

Accepted Answer

bytesクレートをバージョン1.11.1以上にアップグレードしてください。この脆弱性は、リリースビルドにおいてバージョン1.2.1から1.11.0に影響し、BytesMut::reserveで未チェックの加算が原因で発生します。即座にアップグレードできない場合は、一時的な緩和策としてCargoプロファイルでオーバーフローチェックを有効にしてください（例：overflow-checks = true）。ただし、これによりパフォーマンスに影響が出ることに注意してください。最新情報については、アドバイザリGHSA-434x-w66g-qw3rを追跡してください。

Question 2

既存のrustypasteファイルに対して`curl -I`が404を返すのに、通常のダウンロードは正常に動作するのはなぜですか？

Accepted Answer

`curl -I` は HTTP の `HEAD` リクエストを送信します。Rustypaste のファイル配信エンドポイントは `GET` リクエストを処理しますが、ファイルが存在していても `HEAD` に対しては `404` を返します。回避策として、ヘッダーのみを表示しながら `GET` リクエストを強制します:

```sh
curl -X GET -I http://127.0.0.1:8000/lUfQuT7L.png
```

または、通常の `GET` リクエストでステータスコードを確認します:

```sh
curl -sS -o /dev/null -w '%{http_code}
' http://127.0.0.1:8000/lUfQuT7L.png
```

これは `200` を返すはずです。サーバー側の修正により、エンドポイントが `HEAD` リクエストに対しても `200` を返すようになる可能性があります。

Question 3

Rust の time クレートにおけるスタック枯渇によるサービス拒否 (DoS) の脆弱性 RUSTSEC-2026-0009 を修正する方法は?

Accepted Answer

`time` クレートをバージョン `0.3.47` 以降にアップグレードしてください。このバージョンでは再帰深度制限が追加され、スタックを使い果たす代わりにエラーを返します。`cargo update -p time` を実行し、`Cargo.lock` で `time >=0.3.47` が使用されていることを確認してください。`0.3.6` より前のバージョンは影響を受けません。すぐにアップグレードできない場合は、スタック使用量が入力長に比例して増加するため、RFC 2822 解析に渡されるユーザー提供の入力の長さを制限してください。

Question 4

webpki-roots（信頼されなくなった emSign ルート証明書）に関する RUSTSEC-2026-0381 の cargo audit 失敗を修正する方法は？

Accepted Answer

中間秘密鍵が公知となっている侵害済みの `emSign ECC Root CA - G3` ルートを削除した `webpki-roots` バージョン 1.0.10 以降にアップグレードしてください。`cargo update -p webpki-roots` を実行して Cargo.lock 内のバージョンを更新し、`cargo tree -i webpki-roots` で確認し（1.0.10 以上と表示される必要があります）、`cargo audit` を再実行してください。0.26.x 互換パッケージに依存している場合：`webpki-roots` 0.26.11 には独立したトラストストアがなく、1.x の親依存関係からルートを再エクスポートしているため、その親が 1.0.10 以上に解決されるようにする必要があります（例：`cargo update -p webpki-roots@1.0.9`）。0.26.11 がインストールされていても、古い 1.x の親は脆弱なままです。なお、これには通常、自身の Cargo.toml を変更するのではなく、`rustls-webpki`/`reqwest`/`tokio-rustls` などの依存クレートのロックファイルエントリを推移的に更新する必要がある点に注意してください。

Question 5

tokio::time::Interval（Tokio v1.54.0）における RUSTSEC-2026-0384 の競合状態を修正する方法

Accepted Answer

Tokio v1.54.0 には、`Interval::poll_tick`（`.tick().await` を含む）とマルチスレッドランタイムのタイムドライバーとの間に競合状態があり、データ競合、use-after-free、アサーションパニック、ヒープ破壊を引き起こします。影響を受けるのは `Interval` のみで、`Sleep` と `Timeout` は安全です。修正するには、パッチ適用済みリリース 1.54.1 の tokio >=1.54.0 にアップグレードします: `cargo update -p tokio` を実行するか、Cargo.toml に `tokio = "1.54.1"` を設定し、その後 `cargo tree -i tokio` で確認してください。あるいは、バージョン <1.54.0（例: `tokio = "1.53"`）にダウングレードしてください。注意: v1.54.0 は crates.io から yank されているため、新規のビルドではそれに解決されません。このアドバイザリを検出するために、CI に `cargo audit` を追加してください。

rustypaste

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト