Snapdragon X2の公式サポート、24.04 LTSからのLTSアップグレード開始、カーネルの更新ポリシーの周期変更

Snapdragon X2の公式サポート

QualcommのSnapdragon X2シリーズにおけるUbuntuのネイティブサポートが近日登場することが予告されています。リリースは2027年予定です。

Snapdragon X2はSnapdragon Xの後継にあたる、「⁠Windowsも動く」ハイエンドのArm SoCです。今回の発表では「Ubuntuがそのまま動く」ということがアピールされており、前世代のSnapdragon Xの「Concept」リリース（＝コミュニティベース）でUbuntuが動作する形ではなく、Canonicalによる商業サポートを含む「フルの」Ubuntuエコシステムが提供されることになります。

リリースでは「OEM向け」についても触れられており、おそらく「Snapdragon X2搭載PC」の中にはUbuntuをプレインストールしたモデルも登場することになるでしょう（それが日本で入手しやすい形になるかどうかはともかく⁠）⁠。

24.04 LTSからのLTSアップグレード開始

UbuntuのLTSリリースには、次のLTSへの、つまり中間リリースをスキップした形でのアップグレードをサポートする「LTSアップグレード」機能があります。通例これは「新しいLTS」のポイントリリースが登場してから開放されます。

26.04.1のリリースにあわせて、24.04 LTSから26.04 LTSへのアップグレードが有効になったことがアナウンスされています[1]。

Rust版coreutilsの互換性への警戒はありつつ、そろそろ22.04 LTSをどうするか、つまり24.04 LTSに更新した上でステイするか、あるいは26.04 LTSまで更新してしまうか、といったことを検討する時期です。

カーネルの更新ポリシーの周期変更

Ubuntuのリリース後のカーネルの更新は、これまで「機能改善を取り込む修正（ただしSRUポリシーは守られるので劇的な変化は起きないもの）を4週間単位で行い、それらをベースにした2週間周期のセキュリティアップデートがリリースされる」というモデルで行われてきました。

おおむね毎月「バグ修正版」がリリースされ、そのバグ修正版をもとにした「セキュリティ修正版」が2週間ペースで登場するという形です。このプロセスが変更され、今後は「毎週カーネルをリリースする」形になることがアナウンスされました。

このモデルはこれまでの「4週間単位で登場する、機能改善を取り込む修正」に相当するものに毎週着手し、着手から2週間ほどでリリースし続けるという方法で実現されます。

このリリースモデルの詳細は次のとおりです。

毎週1回、新しいカーネルパッケージの開発が着手されます。
着手後、カーネルの準備（各種パッチの取り込み）と最低限のテストに1週間、より広範なテストに1週間が投入されます。これにより、着手から2週間でリリースが行われます。
proposedポケットには「1週間の広範なテスト」が開始された段階でパッケージが投入されます。自前の環境で1週間先行してテストを行う場合（あるいは先行して新しいカーネルパッケージを利用したい場合）に利用します。
重篤なセキュリティ問題（のうち、カーネルにまだパッチが取り込まれていないもの）への対応については、この方式でリリースされるカーネルパッケージが提供されるまでのあいだ「しのぐ」ための緩和策についての情報が提供されます。

ユーザーとしては、「⁠毎週カーネルがリリースされる」「⁠いわゆるゼロデイ攻撃からの対処までは2週間＋αかかることがある[2]」ということを覚えておくと良さそうです。

stonking（Ubuntu 26.10）の開発; Betaの延期、「次」のコードネーム予想

stonkingのBetaのリリースがインフラストラクチャー上の問題により少しだけ遅延しています。正式なリリースは10月15日のままで、これから2週間の間にBetaとRelease Candidateがリリースされ、そのQAが行われるという厳しめのスケジュールになりました。

なお近年のUbuntuではおなじみになりつつある「次のコードネーム予想」スレッドも準備されて盛況を博しており、開発終盤の雰囲気になりつつあります。

……しかしながら、搭載される予定の音声入力インターフェースである「Myna」の設定ユーティリティはまだPPA上にあり、もう少しだけ波乱が起きるかもしれません。

その他のニュース

AIエージェント向けの隔離シェル（NVIDIA製）であるOpenShellを、k8sクラスター上で実行する環境をCharmで構築できるCharmed OpenShellのアルファ版がリリースされています。Microcloud上で動作するCanonical Kubernetes環境で実行される形で、冗長構成を含めたクラスター設計とデプロイメントを自律的に実行できるとされています。

注目すべきセキュリティー的な視点：SNDL/HNDLに備える

「パスワードの定期変更」は、セキュリティ文脈では比較的よく語られる、しかしもはや古くなった『かつてのベストプラクティス』です。

クレデンシャルの定期的なローテートという意味では一定の意味はあるものの、ユーザーにパスワードの定期変更を強制することで発生する諸問題、つまり「安易なパスワードを使ってしまう」「⁠パスワードを書いた紙をどこかに貼ってしまう」といった攻撃しやすいポイントが生まれることから、現在のNIST SP 800-63では非推奨から「禁止」（⁠SHALL NOT）に切り替わりつつあり（第4版で切り替え⁠）⁠、「⁠強制することでむしろ悪い状況をもたらす」ものとして撤廃されようとしています。

一方で、「⁠クレデンシャルの定期ローテート」が機能する場面もあります。各種APIのアクセスキーのような、システムが自動的に出力するようなものであれば、「⁠知らないあいだに流出していた」というシナリオでの被害を限定するために、定期的なローテートはむしろ強く推奨されるものです。

こうした「適切なローテーション」という意味では、覚えておくべき概念としてSNDL/HNDLと呼ばれる攻撃手法と、それに対して脆弱な暗号系の扱い、というものがあります。

Ubuntu 26.04 LTSを利用しているユーザーは、もしかすると（特に、ネットワーク機器のようなアプライアンス的なものに）SSH接続をした時に、次のようなメッセージを目にしたことがあるかもしれません。これはOpenSSH 10.1以降、「⁠WarnWeakCrypto」設定が有効な場合に出力されるもので、その内容のとおり「Store Now, Decrypt Later（SNDL⁠）⁠」タイプの攻撃に対して脆弱な暗号系での接続になっていることを警告しています。

SNDLは「Harvest Now, Decrypt Later（HNDL⁠）⁠」⁠「⁠Capture Now, Decrypt Later（CNDL⁠）⁠」とも呼ばれます。この「統一された用語がない」混乱が、比較的新しい概念であることを良く示していると言えるでしょう。

** WARNING: connection is not using a post-quantum key exchange algorithm.**
** This session may be vulnerable to "store now, decrypt later" attacks.**
** The server may need to be upgraded. See https://openssh.com/pq.html**

この警告は、接続先とのネゴシエーションの結果、PQC（ポスト量子暗号）を用いた接続が確立できなかった場合に出力されます。

警告に表示されているhttps://www.openssh.org/pq.htmlを見ると分かるように、「⁠その通信セッションを盗聴されていた場合、おそらく将来的に有限時間で解読される⁠」⁠、つまり「そのセッションでは、秘匿されるべき情報、個人情報やクレデンシャルのようなものを流すべきではない⁠」⁠、という意味です。危殆化しつつある暗号として捉え、平文での通信に近しい扱いが必要な状況にあると認識するのが妥当でしょう。

この警告そのものは妥当なもので、社会的な趨勢にも即したものです。ホワイトハウスが示した通達のような流れもあり、「⁠リスクのある暗号系上では秘匿されるべき情報を扱わない」という対応が常識になっていく必要があります。

一方で、もしそのセッションで秘匿されるべき情報を扱わないのであれば（つまり「telnetでも許容される」ような通信の範囲ではあるものの、リアルタイムでの成りすましや改竄を防ぐことができれば十分であれば⁠）⁠、そこまで警戒するべきものでもありません。「⁠そのSSHセッション」のログインに使うクレデンシャルを後日、つまり非PQC暗号を破ることができるような量子コンピューター（あるいは量子コンピューター用のアルゴリズム）が成立するまでの猶予期間のあいだに置き換えることができるのであれば、「⁠その日のセッション」を中断するべき理由ではありません。

このことを考えると、「⁠SNDL攻撃が成立してしまう通信経路」で流れるパスワードについては、安全でなくなりつつある暗号系を排除するのと同じように、「⁠流してしまったクレデンシャルをローテートする」目的で更新する、という対応も必要になります。

暗号系の棚卸しや一覧の作成と併せて、「⁠危殆化しつつある暗号系を利用している」システムにおいて適切に警告し、そして「警告を正しく扱える人」を増やす必要があります。「⁠流してよいもの」「⁠流してはいけないもの⁠」⁠、あるいは「あるシステムで流れるもの」を管理できていればこうした問題も適切に扱うことができますが、現実としてこれらを今の段階で整理できているシステムは多くないはずです。