Pull Request on 2026年01月03日

dotnet/runtimeにマージされたPull RequestをAIで日本語要約

注意点

このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。


目次

  1. #122830 Fix NullReferenceException in SerialPort event callbacks when handler unsubscribes during invocation
  2. #122825 Fix trailing data handling with CertificateRevocationListBuilder.LoadPem.
  3. #122816 Remove managed implementation from SP800-108 on Windows
  4. #122812 Remove use of BCryptDeriveKeyPBKDF2.
  5. #122805 Fix FromBase64Transform buffer sizing and output buffer handling
  6. #122637 Fix thread-safety issue in DriveInfo.GetDrives() on macOS by replacing getmntinfo with getfsstat

#122830 Fix NullReferenceException in SerialPort event callbacks when handler unsubscribes during invocation

  • 作成者: @Copilot
  • 作成日時: 2026年01月03日 02:46:41(UTC)
  • マージ日時: 2026年01月03日 15:39:27(UTC)
  • ラベル: area-System.IO.Ports

概要

SerialStream.EventLoopRunnerでイベントハンドラーが一度だけチェックされるが複数回呼び出される問題を修正しました。ハンドラーが最初の呼び出し中にアンサブスクライブすると、その後の呼び出しでNullReferenceExceptionが発生していました。null条件演算子(?.Invoke)を使用して各呼び出し前に安全にチェックするように変更しました。

変更内容

  • ファイル: src/libraries/System.IO.Ports/src/System/IO/Ports/SerialStream.Windows.cs
  • 主な変更:
    • CallReceiveEventsCallErrorEventsCallPinEventsの3つのメソッドを修正
    • 従来の単一のnullチェック後の複数呼び出しから、各呼び出し時にnull条件演算子を使用

修正例:

// 修正前(危険)
if (stream.DataReceived != null)
{
    stream.DataReceived(stream, ...);  // ここでアンサブスクライブ
    stream.DataReceived(stream, ...);  // NullReferenceException
}

// 修正後(安全)
stream.DataReceived?.Invoke(stream, ...);
stream.DataReceived?.Invoke(stream, ...);

パフォーマンスへの影響

影響なし。null条件演算子は標準的なパターンで、パフォーマンス低下はありません。正常に機能するコードの動作は変わりません。

関連Issue

dotnet/runtime#119156

その他

  • テスト結果:954個全テスト合格(832個はCI環境でスキップ)
  • リスク評価:低(標準的なnull安全パターンを使用)
  • .NET 9以降ではNuGetパッケージのバージョン管理が自動化されるため、手動編集は不要

#122825 Fix trailing data handling with CertificateRevocationListBuilder.LoadPem.

  • 作成者: @vcsjones
  • 作成日時: 2026年01月02日 18:25:19(UTC)
  • マージ日時: 2026年01月03日 15:42:02(UTC)
  • ラベル: area-System.Security

概要

CertificateRevocationListBuilder.LoadPemメソッドにおいて、PEM形式のデータ内に末尾データが存在する場合の処理を改善しました。従来はアサーション失敗で対応していましたが、適切な例外を発生させるよう修正し、DERリーダーが末尾データを検証するように強化しています。

変更内容

  • CertificateRevocationListBuilder.Load.cs

    • PEM内の末尾データをブロックする処理を追加
    • DER読み込み時のアサーションを実際の例外処理に変更(6行追加、1行削除)
  • CrlBuilderTests.cs

    • 末尾データを含むPEM形式のテストケースを追加(19行新規追加)

パフォーマンスへの影響

影響なし

関連Issue

#122823

その他

  • DERリーダーがデータの完全性を検証しないため、末尾の不正なデータが見落とされる可能性がありました
  • 本修正により、LoadPemメソッドが不正な形式のCRLデータを明示的に拒否するようになり、セキュリティと信頼性が向上します
  • 複数のレビュワー(bartonjs、stephentoubなど)による確認を経ています

#122816 Remove managed implementation from SP800-108 on Windows

  • 作成者: @vcsjones
  • 作成日時: 2026年01月02日 02:16:06(UTC)
  • マージ日時: 2026年01月03日 15:45:08(UTC)
  • ラベル: area-System.Security

概要

Windows 7専用だった SP800-108 HMAC Counter KDF のマネージド実装を削除するPRです。不要になった手動実装を廃止することで、NativeAOT の効率性向上に貢献します。Windows では CNG(Cryptography API: Next Generation)のネイティブ実装のみを使用します。

変更内容

  • SP800108HmacCounterKdf.Windows.cs: マネージド実装ロジックを削除、CNG実装への委譲に簡素化(36行→4行)
  • SP800108HmacCounterKdfImplementationCng.cs: 不要な手動実装コードを削除(28行→1行)
  • csproj: 関連するコンパイル対象ファイルの記述を削除(3行削除)

パフォーマンスへの影響

改善あり - NativeAOT コンパイル時のメタデータとコードサイズが削減されます。ランタイム性能は向上し、メモリフットプリントも減少すると予想されます。Windows プラットフォームではネイティブの CNG API を直接使用するため、マネージド層のオーバーヘッドが削減されます。

関連Issue

#71075

その他

Windows 7 のサポート終了に伴う クリーンアップ作業の一部です。このPRは大幅なコード削減(合計67行削除)を実現し、保守性も向上します。


#122812 Remove use of BCryptDeriveKeyPBKDF2.

  • 作成者: @vcsjones
  • 作成日時: 2026年01月01日 03:32:54(UTC)
  • マージ日時: 2026年01月03日 02:31:18(UTC)
  • ラベル: area-System.Security

概要

Windows 7は既にサポート対象外となったため、BCryptDeriveKeyPBKDF2 APIの使用を削除するPRです。PBKDF2実装をWindows 7専用の古いAPI呼び出しから移行させ、コードベースを整理します。これによりレガシーAPI依存性が排除され、メンテナンス性が向上します。

変更内容

  • Interop.BCryptDeriveKeyPBKDF2.cs (削除)

    • Windows 7向けBCryptDeriveKeyPBKDF2のP/Invoke定義を完全削除(26行削除)
  • Pbkdf2Implementation.Windows.cs (大幅削除)

    • BCryptDeriveKeyPBKDF2呼び出し部分を削除(50行削除)
    • 代替実装への切り替え
  • System.Security.Cryptography.csproj (削除)

    • BCrypt相互運用性に関連する参照を削除(2行削除)

パフォーマンスへの影響

影響なし(または改善の可能性)

  • Windows 7はサポート対象外のため、実運用環境では影響なし
  • より新しいAPIへの統一により、最新Windowsでは動作最適化の余地あり

関連Issue

その他

本変更はWindows 7サポート廃止に伴う段階的な技術負債削減の一部です。セキュリティ暗号化ライブラリ領域の保守者による監査が既に完了しており、安全な削除となっています。


#122805 Fix FromBase64Transform buffer sizing and output buffer handling

  • 作成者: @Copilot
  • 作成日時: 2025年12月31日 17:42:47(UTC)
  • マージ日時: 2026年01月03日 15:51:41(UTC)
  • ラベル: area-System.Security

概要

FromBase64Transformの2つのバグを修正します。1つ目は、前のブロックから保持されたバイト列がある場合にCryptoPoolからのレンタルサイズが不足する問題で、inputCountではなくbytesToTransformを使用するよう修正しました。2つ目は、出力バッファが不足している場合の例外処理を改善し、Debug.Assert失敗と不正なFormatExceptionではなく適切にArgumentOutOfRangeExceptionをスローするようにしました。

変更内容

  • Base64Transforms.cs: CryptoPool.Rent()呼び出しを2箇所でinputCountからbytesToTransformに変更。Base64.DecodeFromUtf8OperationStatus.DestinationTooSmallを返した場合の処理を追加。
  • Base64TransformsTests.cs: 3つの新しいテストケースを追加
    • TransformBlock_PartialBlockFollowedByPowerOfTwoInput_DoesNotThrow
    • TransformFinalBlock_PartialBlockFollowedByPowerOfTwoInput_DoesNotThrow
    • TransformBlock_OutputBufferTooSmall_ThrowsArgumentOutOfRangeException

パフォーマンスへの影響

影響なし。変数の再利用で実装しており、追加の計算コストはありません。

関連Issue

  • #122804(CryptoPoolレンタルサイジングバグ)
  • #122807(出力バッファ不足時の例外処理)

その他

  • リスク評価:低。最小限の変更で、既に計算済みの変数を使用
  • 2023年以降コードが変更されていないため、この問題は長期間存在していた可能性があります
  • 部分ブロック後に2の累乗に近いサイズのデータを処理する特定のシナリオでのみ発生します

#122637 Fix thread-safety issue in DriveInfo.GetDrives() on macOS by replacing getmntinfo with getfsstat

  • 作成者: @Copilot
  • 作成日時: 2025年12月18日 11:13:22(UTC)
  • マージ日時: 2026年01月03日 17:36:49(UTC)
  • ラベル: 指定なし

概要

macOS上でDriveInfo.GetDrives()が複数スレッドから並行呼び出しされた際にランダムなAccessViolationExceptionを発生させる問題を修正。スレッドセーフでないgetmntinfo()を、呼び出し側でバッファを確保するgetfsstat()に置き換えることで解決します。

変更内容

  • ファイル: src/native/libs/System.Native/pal_mount.c
  • 主な変更:
    • getmntinfo()からgetfsstat()への置き換え
    • 明示的なメモリ割り当て/解放処理の追加(C++互換性のための構造体キャスト付き)
    • MNT_NOWAITフラグの使用により遅いファイルシステムでのブロッキング回避
    • マウント数増加時の自動リトライループ実装
    • バッファサイズの整数オーバーフロー対策(multiply_s使用)
    • INT_MAXチェックとgetfsstatパラメータへのintキャスト

パフォーマンスへの影響

軽微な懸念あり: リトライループにより、マウント数が増加した場合は複数回のgetfsstat()呼び出しが発生する可能性があります。ただし、一般的なシステムではマウント数の変動は稀であり、実質的なパフォーマンス低下は最小限と考えられます。

関連Issue

  • dotnet/runtime#122634(元の問題報告)

その他

  • 回帰: なし(.NET 6, 7, 8で既存の未解決問題)
  • リスク: 低(getfsstat()getmntinfo()の基盤API、macOS/BSDのみに影響)
  • テスト: 全6つのDriveInfoテスト合格、Linux環境でも検証済み