2026/03/05 9:21

パッケージマネージャーは冷却が必要です

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

主なメッセージ：
パッケージエコシステムは、最近のサプライチェーン攻撃を抑制するために「依存関係クールダウン」機構（新しく公開されたパッケージが即座に使用できないようにする設定可能な待ち時間）を採用しつつあります。目標は、全てのマネージャーでサポートできる
exclude-newer-than=<duration>
（例：7d）のようなグローバルに構成可能なフラグです。

重要性
Seth Larson のリクエストと William Woodruff が 2025 年末に行った分析では、最近の攻撃のうち 10 件中 8 件が 1 週間以内に実行できることが示されました。これがクールダウンを導入してその時間窓を閉じる動機となっています。

各エコシステムでの現状：
JavaScript: pnpm (
minReleaseAge
v10.16, 2025 年 9 月)、Yarn (
npmMinimalAgeGate
v4.10.0, 2025 年 9 月)、Bun (
minimumReleaseAge
v1.3, 2025 年 10 月)、npm (
min‑release‑age
v11.10.0, 2026 年 2 月)、Deno (
--minimum-dependency-age
)。
Python: uv (
--exclude-newer
, 相対期間をサポートする v0.9.17 Dec 2025) と pip (
--uploaded-prior-to
, 絶対タイムスタンプを使用する v26.0 Jan 2026)。
Ruby: ネイティブサポートなし。gem.coop のベータサービスは新しい gem に 48 時間の遅延を課し、Bundler ユーザーにツール変更なしで影響します。
Rust: Cargo は RFC とレジストリ側クールダウンインフラ（v1.94 Mar 2026）を持ち、
cargo update foo --precise …
でオプトイン可能。サードパーティラッパー
cargo-cooldown
も存在します。
Go, Composer, NuGet, .NET: 提案段階または初期施行段階にあり、Dependabot はすでに NuGet にクールダウンを適用しています（2025 年 7 月以降）。

サポートツール：
Renovate、Dependabot、Snyk、および npm‑check‑updates は、さまざまなデフォルトでクールダウンロジックを実装またはサポートしています。zizmor の
dependabot-cooldown
、StepSecurity の GitHub PR チェック、OpenRewrite、pinact、prek などの監査ツールはクールダウン設定の挿入を自動化します。

用語と相互運用性：
各エコシステムでは
cooldown
、
minimumReleaseAge
、
min-release-age
、
npmMinimalAgeGate
、
exclude-newer
など異なる名前が使われており、クロス言語プロジェクトを複雑にしています。あるツールは再現性のため絶対タイムスタンプを強制し、別のツールは相対期間でスライディングセキュリティウィンドウを使用します（uv は ISO 8601 とフレンドリー文字列両方をサポート、pip は単純な日数を好みます）。

広い文脈：
apt、brew、Fedora などのシステムパッケージマネージャはすでに暗黙的なレビューウィンドウを提供しています。言語エコシステムに明示的な遅延を追加すると、人間のゲートキーパーが重複し、不要なコストが発生します。そのためクールダウンは高速リリース環境向けのターゲットセキュリティ対策です。

将来展望：
提案が成熟するにつれて、より多くのエコシステムがクールダウンを採用し、オープンソースプロジェクトは言語間で構成を統一するために共有フラグやラッパーを標準化できるようになります。これらの対策はセキュリティを強化しますが、ビルドパイプラインの複雑さも増し、クロス言語依存関係の更新速度が遅くなり、リリースサイクルに影響を与える可能性があります。

主なポイント： 改良された要約は、主要リストからすべての重要点を保持し、不必要な推測を避け、明確で簡潔なナラティブを提示し、曖昧な表現を削除しています。

本文

この投稿は、Seth Larson が「パッケージマネージャー全体でグローバルに設定できる exclude-newer-than（例：

7d

）を導入し、自律的な悪用の応答時間を人間が介入できるレベルへ戻す」ことを依頼して作成されました。
彼の提案は次のようにまとめられます。

攻撃者がメンテナーの認証情報を乗っ取ったり、休眠中のパッケージを掌握した場合、悪意あるバージョンを公開し、自動化ツールがそれを数千のプロジェクトへ取り込むまで誰も気付かないまま待つことです。William Woodruff は 2025 年 11 月に依存関係クーリングダウンについて提唱し、1 ヶ月後にリデュース版で「パッケージバージョンをレジストリ上に一定期間（最低でも数日）置いておくまでインストールしない」ことがコミュニティとセキュリティベンダーに問題を指摘する時間を与えると述べました。
彼が検証した 10 件のサプライチェーン攻撃のうち、8 件は機会窓が 1 週間未満であったため、たとえ 7 日程度のクーリングダウンでもほぼすべてを阻止できるという結論に至ります。

ツールごとに呼び名は異なり（cooldown, minimumReleaseAge, stabilityDays, exclude-newer など）、実装もロールリング期間か絶対時刻か、直接依存だけか転移依存までを対象にするか、セキュリティ更新が除外されるか等で差があります。しかし、過去一年での採用は驚くほど速いです。

JavaScript

パッケージマネージャー	追加された機能	発表時期
pnpm	`minimumReleaseAge` （直接・転移依存共に）＋信頼できるパッケージを除外する `minimumReleaseAgeExclude` リスト	v10.16 (2025 年9月)
Yarn	`npmMinimalAgeGate` （分単位で設定）＋除外リスト `npmPreapprovedPackages`	v4.10.0 (同月)
Bun	`minimumReleaseAge` を `bunfig.toml` から設定	v1.3 (2025 年10月)
npm	`min-release-age`	v11.10.0 (2026 年2月)
Deno	`--minimum-dependency-age` （ `deno update` ・ `deno outdated` で使用）

6 ヶ月で 5 つのパッケージマネージャーが導入。競合ツール間での機能統一は前例がほとんどありません。

Python

パッケージマネージャー機能名発表時期

パッケージマネージャー	機能名	発表時期
uv	`--exclude-newer` （絶対時刻）＋相対期間 ( `1 week` , `30 days` ) とパッケージ別オーバーライド `exclude-newer-package`	v0.9.17 (2025 年12月)
pip	`--uploaded-prior-to` （絶対時刻のみ）	v26.0 (2026 年1月)

--exclude-newer

（絶対時刻）＋相対期間 (

1 week

30 days

) とパッケージ別オーバーライド

exclude-newer-package

v0.9.17 (2025 年12月)

pip

--uploaded-prior-to

（絶対時刻のみ）

v26.0 (2026 年1月)

相対期間サポートは pip には未実装です。

Ruby

Bundler と RubyGems はネイティブにクーリングダウンを持ちませんが、コミュニティ運営の gem サーバ gem.coop がベータ版で新規公開パッケージに 48 時間の遅延を課しています。
インデックスレベルで遅延を適用すれば、gem.coop エンドポイントを指す Bundler ユーザーはツールやワークフローを変更せずにクーリングダウンが有効になります。

Rust, Go, PHP, .NET

言語	状況
Cargo	RFC が進行中。レジストリ側のインフラは Cargo 1.94 (2026 年3月5日リリース) で安定化予定。 * アクセプションリストなし、 `cargo update foo --precise 1.5.10` でオプトインし、ロックファイルに記録。 * 一方で `cargo-cooldown` はサードパーティラッパーとして開発者マシンでクーリングダウンを検証する概念実証です。
Go	`go get` , `go mod tidy` 用のオープンプロポーザルが存在。
Composer	2 件のオープンイシュー。
NuGet	イシューは開いているが、Dependabot を利用する .NET プロジェクトは 2025 年7月から更新ボット側でクーリングダウンを受けています。

依存関係更新ツール

ツール	機能名	備考
Renovate	`minimumReleaseAge` （旧 `stabilityDays` ）「pending」ステータスで時間が経過するまで待機。 `security:minimumReleaseAgeNpm` で npm パッケージのデフォルトを 3 日に設定。
Dependabot	`dependabot.yml` に cooldown ブロック（ `default-days` , `semver-major-days` 等）。セキュリティ更新はクーリングダウンをバイパスします。
Snyk	自動 PR で 21 日の固定クーリングダウン（非設定可）。
npm‑check‑updates	`--cooldown` に期間接尾辞 ( `7d` , `12h` ) を許容。

設定確認ツール

zizmor – v1.15.0 で
```
dependabot-cooldown
```
の監査ルールを追加、デフォルト閾値は 7 日。自動修正も可能。 |
StepSecurity – GitHub PR チェックで npm パッケージのクーリングダウン期間内にリリースされたものを拒否。 |
OpenRewrite –
```
AddDependabotCooldown
```
レシピで Dependabot 設定ファイルへ自動追加。 |
GitHub Actions –
```
pinact
```
で
```
--min-age
```
フラグ、Rust 製
```
prek
```
は
```
--cooldown-days
```
を付与。 |

現状未対応

Go, Bundler, Composer, pip においてクーリングダウンは議論中か部分的にしか実装されていません。Dependabot や Renovate で自動更新を遅延させることはできますが、ローカル実行（

bundle update

go get

等）は数分前のレジストリにあるバージョンを取得できてしまいます。

Maven, Gradle, Swift Package Manager, Dart の pub, Elixir の Hex などでクーリングダウンが議論されているケースは見つかりませんでした。もし知っていればお知らせください。投稿を更新します。

設定名の多様性

サポートしているツール間では、少なくとも十種類以上の設定名が存在します。

cooldown

minimumReleaseAge

min-release-age

npmMinimalAgeGate

exclude-newer

stabilityDays

uploaded-prior-to

min-age

```
cooldown-days
```
,
```
minimum-dependency-age
```

ポリグロットプロジェクトで設定を整えるのは、文章を書くよりも難しいかもしれません。

言語パッケージマネージャー vs. システムパッケージマネージャー

npm, PyPI, RubyGems では

publish

（

npm publish

gem push

）で即座に全世界がインストール可能になります。Dependabot や Renovate がそのウィンドウ内で実行されれば、悪意あるコードは人間の介入無しにプロジェクトへ入り込みます。William が指摘したシナリオです。

対して、apt, Homebrew などのシステムパッケージマネージャーは「公開」から「配布」までを分離します。新しいアップストリームバージョンはレビュー・パッケージ化・ビルドされて初めて

apt install

や

brew install

で利用可能になります。Debian は unstable へ最初にアップロードし、2〜10 日後に testing, さらに別のリリースプロセスで stable に移行します。これは人間がレビューするインターナルクーリングダウンと同等です。

言語エコシステムにレビューウィンドウを追加すると、セキュリティ研究者は悪意ある公開を検知してから自動化ツールがロックファイルへ取り込むまで数日間の時間を確保できます。Homebrew や apt に同じ機能を要求すると、本来人間が管理するプロセスに遅延が加わり、実際には逆に時間とコストが増える可能性があります。

タイムスタンプ問題

```
pip
```
の
```
--uploaded-prior-to
```
と npm の古い
```
--before
```
は絶対時刻を取るため再現性に優れます。
相対期間（例：7 日）はスライディングウィンドウとして機能し、セキュリティ機能として有効です。

uv の

--exclude-newer

は両形式を受け付け、npm では絶対時刻用の

--before

と相対期間用の

min-release-age

が存在します。pnpm, Yarn, Bun, Deno は相対期間のみを許容します。

期間文字列の解析は面倒です。ISO 8601（

P7D

）は曖昧さがなく長いですが、読みやすい文字列（

7 days

）は扱いやすい一方でパーサーが必要です。月・年といった可変長カレンダー単位を処理するには月の知識が必須です。uv は ISO 8601 とフレンドリ文字列を採用し、月・年は除外しています。pip のメンテナーは「日数のみ」を受け付ける方向に傾いています。

タイムゾーンも別問題です。CI サーバが UTC で動作し、開発者のノートパソコンが米国太平洋時間、レジストリが PyPI の設定タイムゾーンを使用していると、6 日 22 時間前に公開されたパッケージがクーリングダウンチェックを通過するかどうかで数時間の差が生じます。

同じ日のほかのニュース

一覧に戻る →

2026/03/08 5:43

CAS番号（化学物質登録番号）

## Japanese Translation: CasNumは、コンパスと定規を用いた幾何学的構成により任意精度算術を実装するPythonライブラリです。数値は平面上の点としてエンコードされ、加算・乗算・除算・論理ゲートなどの演算は、線/点、円、直線と円の交点などの5つの基本的な幾何学プリミティブから構築されます。最適化には、2倍による特殊ケース乗算や剰余計算で最高位ビット（2のべき乗）を除去する手法が含まれています。このライブラリはGame BoyエミュレータのALUに組み込むことを想定しています。CasNumを統合するには、PyBoy の `opcodes_gen.py` を編集するだけで、他のエミュレータコードは変更されません。使用例としては、単純なRSA実装（`python3 -m examples.rsa`）や、幾何学ベースの算術のみで動作させるポケットモンスター赤版（`python3 -m examples.basic`）があります。初回起動に約15分かかりますが、その後はPython の `lru_cache` によりほぼ 0.5–1 FPS で再起動できます。ビュアースクリプト (`casnum/cas/viewer.py`) は幾何学的構成を可視化し自動ズームします。RSA例では手動ズームが必要になる場合があります。依存関係は、sympy（コア）、可視化用のオプション pyglet、テスト用 pytest‑lazy‑fixtures、RSA 用 pycryptodome、および任意で Euclid Postulate V です。インストールは `git clone --recursive` の後に `pip install -r requirements.txt` を実行します。使用している ROM（`2048.gb`）は zlib ライセンス、CasNum コアコードは MIT ライセンス、PyBoy は LGPL v3.0 でライセンスされており、このプロジェクトはオープンソースや教育プロジェクトに適しています。

2026/03/08 6:56

3T ブラインドスポット：米国の非営利団体

## Japanese Translation: **概要** 米国の非営利セクターは年間 **3兆ドル** を管理しており、これはイギリスのGDPを上回る金額ですが、そのうち実際にプログラム費用に充てられるのは **約36％（1,800億ドル）** に過ぎません。残りはオーバーヘッド、スタッフ給与、資金調達に使われています。登録済み非営利団体は **180万人以上** であり、その多くは収益が5万ドル未満の場合 IRS Form 990 の提出義務から免除されているため、セクター全体の大部分が公衆の監視から隠れています。寄付者の信頼感は低下しています。**米国の寄付者の32％が5年以上前よりも慈善団体に不信感を抱いています**（BBB Wise Giving Alliance）、世界的にも三分の一が非営利団体への信頼を失っています（Gallup）。財務的負担は顕著で、**調査対象の非営利団体の36％が2024年末に営業赤字を報告し、10年間で最高水準となりました**。また **41％しか全職員に生活賃金を支払えません**。資金提供者は通常オーバーヘッドを約15 % に抑えるよう指示しますが、多くの非営利団体は管理費に **31 % 近くを使っており、過小報告やコーナーカットが頻発する** ― これは「非営利組織の飢餓サイクル」と呼ばれる現象です。企業会計との大きな違いは顕著です。IRS Form 990 は年間一度提出され、公開までに **12–18か月** を要し、監査済み財務諸表や詳細なプログラム内訳が欠如しています。一方で公的企業は **10-K（年次）、10-Q（四半期）、8-K（重要事象）** を提出し、60日以内に監査済みの声明を求められます。このコンプライアンス中心の枠組みが可視性の問題を生み出し、寄付者の信頼を侵食しています。国際的には、英国で実施された研究で **ウガンダの井戸の45％が非営利団体によって資金提供されましたが、機能していませんでした**。これにより 2億1,500万〜3億6,000万ドル相当のリソースが無駄になっています—非効率性の重大さを示しています。既存技術（カメラ・センサー・衛星画像）はリアルタイムで成果を追跡できる可能性がありますが、現在の報告規則ではそのような機能は義務付けられていません。非営利セクターの将来は、コンプライアンス重視から真の透明性と説明責任への転換にかかっています。この変革なしには、非営利団体は営業赤字と寄付者の懐疑心を続けるでしょう。変革が実現すれば、信頼を回復し持続可能な資金調達を確保できる可能性があります。

2026/03/06 16:17

既存のブリックからLEGO NXTファームウェアをダンプする（2025）

## Japanese Translation: > 著者はPybricksプロジェクトで作業している際、オリジナルのファームウェアバージョン 1.01を動作させていた中古Lego NXTを入手し、このファームウェアの保存コピーが存在しないこと（利用可能なのは新しい 1.03のみ）に気づきました。 > > NXTのAT91SAM7S256 MCU上では、SAM‑BA PEEK/POKE を呼び出すことはできますが、それを行うとファームウェアを書き換えてしまい、古いMCUにはモダンなデバッグインターフェースが欠けているためJTAGも実用的ではありません。ロボットのプログラムは制限付きメモリ内で動作するバイトコードVMで走るので、著者は低レベル機能に焦点を当てました。 > > PyUSB を介して USB 「Read IO Map」コマンドを送信し、`0x100d3d`（フラッシュの約 3 KiB）に位置するVMの書き込み可能な関数ポインタ `pRCHandler` を読み取りました。32 KiB の書き込み可能 MemoryPool は NOP とカスタム ARM コードで埋めることができ、`pRCHandler` をこのプール内のアドレスにリダイレクトすることで任意の直接コマンドをそのコードとして実行させることができます。 > > 著者は、受信パケットから4バイトのアドレスを読み取り、そのアドレス上のワードを返す組み込みアセンブリを挿入し、元のハンドラを置き換えました。この乗っ取られたハンドラを利用して、USB経由で「direct」コマンドをバイト単位で送信し、フラッシュ領域全体（`0x00100000–0x00200000`）を読み取り、完全なファームウェアとユーザーデータを `nxtpwn-dump.bin` にダンプしました。 > > この脆弱性は、ストックファームウェアを実行している任意のNXTで機能し、未改変デバイス上でもベアメタルコードが動作できることを示しています。これにより、保存ツールや自己複製型マルウェアなどの可能性が開かれ、NXTファームウェアの整合性チェックにおける脆弱性も浮き彫りになっています。