はじめに
近年、公開TLS証明書の有効期限が「47日」へと短縮される流れが進んでいます。一見するとこれは「セキュリティ強化」の話に見えますが、インフラ運用・言語エコシステム・パッケージ配布の観点では非常に大きな副作用を持っています。
この記事では、
- なぜCPANは今でもHTTP/rsyncを捨てていないのか
- なぜPyPI/npmなどは47日時代に苦しくなるのか
- これは技術の遅れではなく「設計思想の違い」だという話
を整理します。
結論（先に）
CPANがHTTPを廃止する予定は、公式にも思想的にも存在しない。それは「遅れているから」ではなく、廃止できない構造と役割を担っているから。
47日証明書で何が変わったのか
証明書が47日になるということは、実質的に以下を意味します。
- 年8回以上の証明書更新が必須
- 人手運用は破綻
- 自動更新できない環境は即死
影響を受けるのはWebサービスだけではありません。
実際に壊れるもの
- パッケージ配布（pip / npm / cargo）
- CI/CD
- 隔離ネットワーク・オンプレ環境
- 古いOS / 組み込みLinux
- 災害・障害時の緊急復旧環境
つまり、「今すぐ1コマンド入れたい」世界が壊れます。
中央集権型パッケージレジストリの弱点
PyPI / npm / crates.io などの特徴は共通しています。
- 中央レジストリ
- HTTPS必須
- 証明書・CAバンドルに強く依存
1回でも証明書更新に失敗すると、以下が全滅します。
- pip install xxx
- npm install
- cargo build
これは「言語の問題」ではなく、配布インフラ設計の問題です。
CPANはそもそも何者なのか
CPANは単一のサービスではありません。
- 世界中の大学・研究機関・個人が運営する
- 独立したミラーの集合体
- 中央運営者が存在しない
そして設計の前提はこれです。
- インターネットは壊れる
- 証明書も壊れる
- だから配布は壊れないようにする
CPANがHTTPを廃止できない（しない）理由
1. 強制できる主体が存在しない
CPANには「HTTPSを必須にする」と決めて強制できる中央権限がありません。各ミラーは独立しており、
- HTTP
- HTTPS
- rsync
- FTP
を各自の判断で提供しています。
2. rsync / HTTPは一次手段
CPANにおいてTLSは「必須」ではありません。
rsync mirror.example.org::CPAN /usr/local/CPAN
証明書が壊れていても、配布は成立します。
3. 壊れた世界で動くことが使命
CPANが生き残ってきた理由は、
- 古いUNIX
- オンプレ
- 隔離ネットワーク
- 初期レスキュー環境
でも最後まで動いたからです。HTTPを廃止すると、これらを切り捨てることになります。それはCPANの存在理由そのものを否定します。
「でもHTTPは危険では？」への答え
CPANのセキュリティモデルは以下です。
- CHECKSUMS
- PAUSEによる作者管理
- 署名（任意）
- ソースコード文化
重要なのは：
TLSは改ざん防止にはなるが、悪意あるコードは防げない
CPANは「経路」より「内容」で安全性を担保しています。
他言語との比較
| エコシステム | TLS依存 | ミラー文化 |
|---|---|---|
| CPAN | 任意 | ◎ |
| RubyGems | やや低 | ○ |
| Maven | 低 | ○ |
| Go Modules | 回避可能 | △ |
| PyPI | 必須 | ✕ |
| npm | 必須 | ✕ |
47日時代に強い配布とは
- 中央依存しない
- rsync / HTTPで同期できる
- ローカルミラーが作れる
- 証明書が壊れても配布できる
これは「古い」思想ではなく、障害前提設計です。
まとめ
CPANがHTTPを捨てないのは技術的遅れではない。47日証明書時代でも生き残るための、意図的な設計である。
証明書は壊れる
中央サービスは落ちる
だから配布は壊れてはいけない
CPANは、その前提を30年守り続けています。
おわりに
「HTTPSを強制すれば安全」という単純な話ではなく、
“壊れた世界で何が残るか”
を考える時代に入っています。47日証明書は、その設計差をはっきり可視化しました。