（CVEパッチが適用された）パッケージバージョンはどのように関連していますか？

Question

発表された脆弱性修正の実際の例を考えると、たとえば、最新の openssl脆弱性修正、およびDistroの報告された修正のスループット（例： GNU/Linux CVE-2016-6309に対するDebianの応答：

_wheezy 1.0.1e-2+deb7u20 fixed wheezy (security) 1.0.1t-1+deb7u1 fixed _

2つの質問があります：

（将来の可能性がある）バージョン1.0.1e-2 + deb7u21perdefinitionが含まれています（またはより良い）修正も、それは若いバージョンです（注：私は架空の例を使用しています、私の質問は一般的で具体的ではないため、u21はまだ存在しません）？
特定の例（GNU/Linux Debian）のwheezyとwheezy (security)の違いは何ですか。「セキュリティの1つ」は、若いバージョンのバージョンを指す場合もあれば、古いバージョンのバージョンを指す場合もあります。

誰かが私のためにこれらにいくつかの光を当てることができれば..それはありがたいです！

grochmal · Accepted Answer

TL; DR：原則としてu20およびそれより大きい番号のパッケージは脆弱であってはなりません（地獄、u1以上はアップストリーム以降、脆弱であってはなりませんパッケージのバージョンは変更されず、u1は脆弱ではありません）。つまり、VVV（アップストリームバージョン、以下を参照）を変更するか、Debianリリースを変更しない限り、異なる番号が使用されます（バージョン規則の詳細な説明については、以下を参照してください）。これは99.9％のケースに当てはまりますが、開発者は間違いを犯し、後で変更を加えると古い脆弱性が目覚めます。しかし、それは非常にまれであり、そのような場合、新しいCVEが発生します。

Debianパッケージの命名規則

ええ、あなたはおそらくこれを苛立たせるでしょうが、Debian FAQはパッケージのバージョン部分を次のように説明しています：

VVVコンポーネントは、アップストリーム開発者によって指定されたバージョン番号です。ここには標準がないため、バージョン番号の形式は「19990513」と「1.3.8pre1」のように異なる場合があります。

RRRコンポーネントはDebianリビジョン番号であり、Debian開発者（またはパッケージを自分でビルドすることを選択した場合は個々のユーザー）によって指定されます。この番号はDebianパッケージのリビジョンレベルに対応しているため、新しいリビジョンレベルは通常、Debian Makefile（debian/rules）、Debian制御ファイル（debian/control）、インストールまたは削除スクリプト（debian/p）の変更を示します。 *）、またはパッケージで使用される設定ファイル内。

しかし、待ってください、それらのVVVとRRRは何ですか？完全な命名規則は次のとおりです。

foo_VVV-RRR_AAA.deb

AAAは単純で、アーキテクチャです。 VVVは、アップストリーム開発者、つまり、あなたの場合はopenssl開発者からのものです（例：1.0.1または1.0.1t、 here を参照）。

最後に、.debをパッケージ化する人に任されているRRRがありますが、これは実際には何でもかまいません。一方、Debianパッケージャは通常、debianバージョン（wheezyの場合はdeb7、jessieの場合はdeb8）といくつかの更新番号に従います。更新番号は連続している必要はなく、前の番号よりも大きい必要があります。これは、パッケージャーがパッケージのテストビルドに失敗したためと考えられます*。

要約すると、.debバージョン文字列とそれに含まれるCVEをリンクするものは何もありません。リリースノートにアクセスして読む必要があります。さらに、多くの場合、パッケージャーとアップストリーム開発者のリリースノートを読む必要があります（パッケージャーには、アップストリーム開発者のリリースノートへのリンクが含まれていることがよくあります）。

（セキュリティ）リポジトリ

プレーンなwheezyの代わりにwheezy (security)が意味するのは、Debianにsecurityのリポジトリの1つとしてaptリポジトリがインストールされているということです。これは通常、次の方法で実行されます。

deb http://security.debian.org/ wheezy/updates main contrib

Security.debian.orgのスタッフはCVEに取り組み、 debianセキュリティトラッカーでそれらすべてのCVEレポートを作成します。セキュリティ上の理由から、必要に応じて新旧のDebianバージョンのパッケージを更新します。 CVEの例を使用すると、jessieのopensslはかなり新しく、jessie (security)は新しく、wheezy (security)は新しいですが、wheezyはまだかなり古いバージョンを使用しています。

これにより、wheezyを使用するシステム管理者は、jessieにアップグレードしなくてもセキュリティ更新プログラムを取得できます。 Debianは信じられないほど堅牢で安定しており、コードの変更によって問題が発生することを恐れて、セキュリティ更新プログラムでパッケージを更新したくないシステム管理者がいます（セキュリティリポジトリを有効にしないだけです）。

これで、セキュリティ担当者は必要に応じて古いパッケージを更新しますパッケージのバックポートを好みます。ただし、VVVを更新する必要がある場合もあります。たとえば、wheezy (security)のopensslは1.0.1tにあり、wheezyのopensslは1.0.1eにあります。これは、おそらく this CVE が原因です。

したがって、wheezy (security)は、下位互換性の観点から、プレーンなwheezyよりも危険ですが、jessieにアップグレードするよりも安全であると言えます。プレーンなwheezyまたはプレーンなjessie（sources.listにはstableリポジトリしかありません）を使用するかどうかを私が知っている限り、決してVVVアップデートを受信しませんaptを介して、RRR部分の更新のみを取得します。

(security)リポジトリと通常のリポジトリで作業するのは異なる人々の集まりであるという事実のおかげで、面白いことが起こることに注意してください。これは（セキュリティ）パッケージが脆弱であるが通常のものは脆弱ではないCVEです。この場合、VVVは同じであり、非-のRRRは同じであるため、問題ありません。セキュリティパッケージはより高く、利用可能な最新のアップデートとしてaptによって選択されます。