use-rustls-ring transitively enables rustls/default (aws-lc-rs), breaking ring-only builds
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 76/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 静か
- 技術スタック
- rust
- 領域
- build-system
調査の方向性
まず、issue に示されている rustls-ring と rustls の Cargo feature 定義を確認し、次に cargo tree -e features を実行して現在の feature chain を確認します。use-rustls-ring が rustls/default を有効にしないよう、optional な rustls feature の参照を更新し、ring-only ビルドに aws-lc-rs が含まれなくなったことを確認します。
索引モデルが issue の本文から書いたものです。
説明
In 0.25.0 the rustls-ring feature is defined as:
rustls-ring = [
"webpki-roots",
"dep:rustls",
"rustls/ring",
"rustls/logging",
"rustls/std",
"rustls/tls12",
]
The "rustls/ring" entries (without ?) also activate the crate's explicit rustls feature:
rustls = [
"webpki-roots",
"dep:rustls",
"rustls/default",
]
which enables rustls/default, i.e. the aws-lc-rs provider. So a downstream crate asking for use-rustls-ring (expecting ring only) ends up with both ring and aws-lc-rs enabled on rustls. cargo tree -e features shows the chain:
electrum-client feature "rustls"
└── electrum-client feature "rustls-ring"
└── electrum-client feature "use-rustls-ring"
Consequences downstream: rustls can no longer auto-select a process-level CryptoProvider, so any other crate in the same binary that relies on the process default panics on first TLS use with:
Could not automatically determine the process-level CryptoProvider from Rustls crate features.
(electrum-client itself is unaffected since it selects its provider explicitly.) We hit this in a project after bumping electrum-client 0.21 -> 0.25: the shared rustls went from ring only to ring + aws-lc-rs + default, and an unrelated tokio-tungstenite connection in the same binary started panicking.
Suggested fix
Use the ? syntax so rustls-ring does not activate the rustls feature:
rustls-ring = [
"webpki-roots",
"dep:rustls",
"rustls?/ring",
"rustls?/logging",
"rustls?/std",
"rustls?/tls12",
]
(0.21 did not have this problem; the regression came with the feature reshuffle in later releases.)
- 主要言語
- Rust
- スター
- 89
- フォーク
- 87
- 平均マージ
- 1時間 25分
- マージ済み PR(30日)
- 4
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
bitcoindevkit/rust-electrum-client のほかの issue
-
[Hardening] Reject non-object JSON notifications without panicking (F-008)対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
[Hardening] Validate legacy block_headers length before slicing (F-007)対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
bitcoindevkit/rust-electrum-client#221 · コメント 1 件 ·
-
discussion new feature
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
bitcoindevkit/rust-electrum-client#211 · コメント 2 件 ·
-
Rework CI to use `cargo-rbmt`再び着手できるかも @luisschwab が 205 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
bitcoindevkit/rust-electrum-client#202 · 担当者 1 名 ·
bitcoindevkit/rust-electrum-client の issue をすべて見る
似ている issue
-
Panic on live viewport resize when unstyled elements exist in display: none subtree対応中かも @GoCoder7 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
DioxusLabs/blitz#1488 ·
メンテナーはふだん 1 日以内に返信
-
🏷️ good first issue enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
S-Needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
vectordotdev/vrl#2042 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信