6 ソースコードのバックポート #
SUSEはバックポートを広い範囲で使用しています。バックポートとは、ソフトウェアの最新の修正や機能をリリース済みのSUSE Linux Enterpriseパッケージにマイグレートすることです。この章では、SUSE Linux Enterpriseソフトウェアパッケージの機能とセキュリティを判断するためにバージョン番号を比較しても当てにならない可能性がある理由について説明します。この章では、SUSEがどのようにしてシステムソフトウェアをセキュアで最新の状態に保ちつつ、SUSE Linux Enterprise製品上でアプリケーションソフトウェアの互換性を維持しているかについても説明します。さらに、公表されているセキュリティ上の問題のうち、ご使用のSUSE Linux Enterpriseシステムソフトウェアでどれが実際に対応済みかを確認する方法、およびご使用のソフトウェアの最新ステータスを確認する方法を学ぶこともできます。
6.1 バックポートを行う理由 #
アップストリームの開発者は、自分が開発するソフトウェアを前進させることを念頭に置いています。多くの場合、バグの修正と新機能の導入が組み合わせられますが、その新機能は詳細なテストをまだ受けていないために、新しいバグを生み出す可能性があります。
配布物の開発者としては、次のものを見分けることが重要です。
バグ修正(機能を中断する限定的な可能性がある)。
変更(既存の機能を中断する可能性がある)。
多くの場合、パッケージがリリースされた配布物の一部になったら、配布物の開発者はアップストリームでのすべての変更を追うことはしません。通常は、最初にリリースされたアップストリームバージョンから離れずに、アップストリームの変更に基づいてパッチを作成してバグを修正します。こうした一連の処理はバックポートと呼ばれています。
一般的に、配布物の開発者が新しいバージョンのソフトウェアを導入するのは、次の2つの場合のみです。
パッケージとアップストリームバージョンの変更内容の差があまりに大きくなり、バックポートが不可能になってしまった場合。
本質的に経年劣化するソフトウェア(マルウェア対策ソフトウェアなど)。
SUSEでは、エンタープライズソフトウェアに対する数多くの考慮事項のバランスをうまく取るために、広い範囲でバックポートを使用しています。こうした考慮事項のうち最も重要なものは次のとおりです。
SUSEのエンタープライズ製品上で使用する製品を構築する際にソフトウェアベンダーが信頼することのできる安定したインタフェース(API)を提供すること。
SUSEのエンタープライズ製品のリリースで使用するパッケージが、単体としてもエンタープライズ製品全体の一部としても、最高品質であり、完全にテスト済みであることを確認すること。
SUSEのエンタープライズ製品に対するその他のベンダーによるさまざまな証明書を維持すること(OracleまたはSAP製品の証明書など)。
SUSEの開発者が、リリース全体に薄く広く注意を拡散させるのではなく、次の製品バージョンの開発に集中できるようにすること。
特定のエンタープライズ向けリリースの内容の明確性を保ち、サポートがそのリリースについて正確かつタイムリーな情報を提供できるようにすること。
6.2 バックポートを行わない理由 #
一般的なポリシールールとしては、当社のエンタープライズ製品に、パッケージの新しいアップストリームバージョンは導入されないことになっています。ただしこのルールは絶対的なものではありません。特定のタイプのパッケージ(特にウィルス対策ソフトウェア内)では、品質確保の観点から選ばれた保守的なアプローチよりも、セキュリティに関する考慮事項の方が重視されます。こうしたクラスのパッケージでは、時として、エンタープライズ製品ラインのリリース済みバージョンに、新しいバージョンが導入されることがあります。
その他のタイプのパッケージについても、バックポートではなく新しいバージョンの導入が選択される場合があります。バックポートの作成が経済的に不可能な場合や、新しいバージョンの導入に対する非常に妥当な技術的な理由が存在する場合などがこれに該当します。
6.3 バージョン番号の解釈に対するバックポートの意味 #
バックポートが実行されているために、SUSEパッケージに特定の問題の修正が含まれているのか、または特定の機能が追加されているのかを、バージョン番号を単純に比較して判断することはできません。バックポートでは、SUSEパッケージのバージョン番号のアップストリーム部分は、単にSUSEパッケージの基となっているアップストリームバージョンを示しているだけです。ここには、対応するアップストリームリリースには存在しないけれどもSUSEパッケージにはバックポートされている修正や機能が含まれている可能性があります。
バックポートが関係する場合にバージョン番号のこの限られた値が問題を引き起こす可能性がある、1つの特定の領域として、セキュリティスキャンツールの使用が挙げられます。セキュリティの脆弱性スキャンツール(または、それらのツールによる特定のテスト)の中には、単にバージョン情報のみに基づいて機能するものがあります。したがって、これらのツールおよびテストでは、バックポートが関係している場合に「false positives」(ソフトウェアが脆弱であると誤って断定されてしまうこと)が生成される傾向があります。セキュリティスキャンツールでレポートを評価する場合は、エントリがバージョン番号に基づくものなのか、それとも実際の脆弱性テストに基づくものなのかを、常に確認してください。
6.4 修正されたバグおよびバックポート機能の確認 #
バックポートされたバグ修正や機能に関する情報が保存されている場所は数多くあります。
パッケージの変更ログ:
tux >
rpm -q --changelog name-of-installed-packagetux >
rpm -qp --changelog packagefile.rpmパッケージの変更履歴を簡単にドキュメント化した出力です。
パッケージの変更ログには、
bsc#1234
(「Bugzilla Suse.Com」)などのエントリが含まれています。これは、SUSEのBugzillaトラッキングシステムのバグ、または他のバグトラッキングシステムへのリンクを示しています。機密保護ポリシーにより、ユーザがこうした情報のすべてにアクセスできるわけではありません。パッケージには、SUSEパッケージに固有の一般的な概要情報を含む
/usr/share/doc/PACKAGENAME/README.SUSE
ファイルが格納されている場合もあります。RPMソースパッケージには、通常のバイナリRPMを個別のファイルとして構築するときに適用されたパッチが含まれます。これらのファイルは、ソースコードの解読に精通していれば解釈することができます。SUSE Linux Enterpriseソフトウェアのソースのインストールについては、6.1.3.5項 「ソースパッケージのインストールまたはダウンロード」を参照してください。SUSE Linux Enterpriseにおけるパッケージの構築については、6.2.5項 「ソースパッケージのインストールとコンパイル」を参照してください。SUSE Linux Enterpriseのソフトウェアパッケージの構築に関する詳細については、「Maximum RPM」ドキュメントを参照してください。
セキュリティ上のバグ修正については、SUSEのセキュリティ告知を参照してください。これらは、
CAN-2005-2495
などの標準化された名前でバグを表すことがよくあります。こうした名前は、Common Vulnerabilities and Exposures (CVE)プロジェクトによって管理されています。