このpython-cffi、python-cryptography、およびpython-xattrの更新では、次の問題を修正します：

修正されたセキュリティ問題：

CVE-2018-10903：finalize_with_tag API内の切り捨てられたタグを介したGCMタグの偽造を修正しました（bsc#1101820）。

修正された非セキュリティ問題：

python-cffiが1.11.2に更新しました （bsc#1138748、jsc#ECO-1256、jsc#PM-1598）：i586上のビルドの失敗を修正しました（bsc#1111657）

ソルトはスナップショット20171129でハイ状態にできませんでした（bsc#1070737）

spec内のpytestを更新して、testingディレクトリに加えてcディレクトリtestsを追加します。

1.11.1 に更新：テストを修正し、廃止されたC APIの使用を削除します

互換性のないバイナリ拡張を提供する3.6.0/3.6.1/3.6.2を修正（解決）します（cpython問題#29943）

3.7.0a1+を修正します

1.11.0 に更新：最新の標準型のchar16_tとchar32_tをサポートします。これらは、wchar_tと同様に機能します：1つのunicode文字を表したり、charN_t *またはcharN_t[]として使用された場合は、unicode文字列を表します。wchar_tとの違いは、既知の固定サイズを持つことです。wchar_tで機能していたすべての場所で機能するはずです（見落としがあれば、問題を報告してください）。set_source（）では、これらの型が指定したCソースで実際に定義されていることを確認する必要があることに注意してください（cdef（）内で使用した場合）。

C99型のfloat_Complexとdouble_Complexをサポートします。libffiはこれらをサポートしていないことに注意してください。これは、ABIモードでは、引き続き、引数や戻り値の型として直接複素数を取るC関数を呼び出すことができないことを意味しています。

複数のスレッドから複数のFFIインスタンスが作成された場合の稀な競合状態を修正しました。（複数のFFIインスタンスを作成する意図はないことに注意してください：インラインモードでは、import cffiの直後にモジュールレベルでffi = cffi.FFI（）を記述する必要があります。また、out-of-lineモードでは、FFIを明示的にインスタンス化しません）。

Windows：CFFI内部エラーメッセージがstderrに出力されるにもかかわらず、stderrが多くのアプリケーションでどこにも表示されないため、コールバックの使用が煩雑になる可能性があります。そのため、埋め込みモードで開始することが特に困難になります。（使い始めると、少なくとも@ffi.def_extern（onerror=...）を使用して、アプリケーションに意味のあるエラーログを送信したり、ログファイルに記録したりできます）。CFFIで新しい点は、Windowsで、CFFIが（rawメッセージをstderrに送信することに加えて）非モーダルMessageBoxを開こうとすることです。
MessageBoxは、プロセスが稼働している間だけ表示されます：通常、クラッシュしたコンソールアプリケーションはすぐに終了しますが、stderrをとにかく表示すべき状況でもあります。

NetBSDでのコールバックのサポートの進捗。

ブール値を返す関数が、FalseまたはTrueの代わりに0または1を返す場合があります。修正しました。

ffi.gc（）は、オブジェクトのサイズ（バイト単位）の推定値を提供するオプションの第3パラメーターを取るようになりました。現時点では、次のGCをより素早く発生させるために、PyPyによってのみ使用されます（問題#320）。将来的には、CPythonにも影響を与える可能性があります（CPython問題31105が解決された場合）。

ドキュメントに注記を追加します：ABIモードでは、APIモードよりも呼び出しが遅い関数オブジェクトが提供されます。何らかの理由で、もっと高速だと見なされているようですが、それは誤りです！

1.10.1 に更新：cdef（）エラーの場合に報告される行番号を修正しました。今気付いたのですが、pycparserは、常に、プリプロセッサーディレクティブの#42 'foo.h'をサポートしていました。これは、「次の行から、foo.hファイルの42行目が始まる」という意味で、これがエラーメッセージに入っています。

1.10.0への更新：

問題#295：PyObject_Malloc（）+memset（）の代わりにcalloc（）を直接使用して、デフォルトのアロケーターでffi.new（）を処理するようにします。ほとんどの配列を操作しないことでffi.new（large-array）を高速化します。一部のOS/Xビルドの修正（「Xcodeのみを使用してCLTを使用しない」）。

いくつかのエラーメッセージを改善します：cffiとそのバックエンドのバージョンが一致しない場合や引数が「複雑すぎる」（しかも、常に機能する構造体ポインターではない）構造体であるためにlibffiを使用して呼び出すことができない関数を呼び出す場合。

一部のあまり使用されないコンパイラ（non-msvc、non-gcc、non-icc、non-clang）のサポートを追加します

ffi.from_bufferの残りのケースを実装しました。すべてのbuffer/memoryviewオブジェクトを渡すことができるようになりました。残っている1つのチェックは、Python 2でのunicode文字列の受け渡しに対するものです（これらはバッファインターフェイスをサポートしますが、大抵は想定外のUTF16/UCS4ストレージの背後にrawバイトを提供します。Python 3では、これが修正され、unicode文字列でmemoryviewインターフェイスがサポートされなくなりました）。

C型の_Boolまたはboolが、読み取り時に、整数としてのバイトの内容ではなく、Pythonブール値に変換されるようになりました。ここでの潜在的な非互換性は、バイトに0や1とは異なる値が含まれている場合に発生するものです。以前は、その値を返すだけでした。
この変更により、CFFIがこのケースで例外を発生させます。ただし、このケースはCにおける「未定義の動作」を意味します。これに依存するライブラリとのインターフェイスが本当に必要な場合は、CFFI側でboolを使用しないでください。また、bool[]の初期化子としてバイト文字列を使用することは今でも有効ですが、\x00または\x01のみを含める必要があります。余談として、ffi.string（）がbool[]で動作しなくなりました（ただし、この関数は最初の0で停止するため、効果はありません）。

ffi.bufferはcffiのバッファタイプの名前になり、ffi.buffer（）は以前と同様に動作しますが、そのタイプのコンストラクターになりました。

ffi.addressof（lib, 'name'）が、out-of-lineモードだけでなく、インラインモードでも動作するようになりました。これは、グローバル変数のアドレスを取得するのに便利です。

問題#255：プリミティブ型のcdataオブジェクト（整数、浮動小数、文字）が比較され、値で順序付けられるようになりました。たとえば、<cdata>は42に等しいかを比較し、<cdata b>はb'A'に等しいかを比較します。Cとは異なり、<cdata>はffi.cast（'unsigned int', -1）に等しいかを比較しません：より小さいかを比較します。これは、-1PyPy：ffi.new（）とffi.new_allocator（）で「メモリ負荷」が記録されなかったためです。これにより、ffi.new（）を頻繁に呼び出したり、大きな配列で使用したりした場合に、GCの実行頻度が低くなります。PyPy 5.7を修正しました。

+または-を含む数式に対するffi.cdef（）をサポートします。オーバーフローが発生しないことを前提としています。定数に対する任意の算術演算のより一般的なサポートを追加する前に、この前提を修正する必要があります。

</cdata></cdata></cdata>

1.9.1 に更新：最終フィールドとして可変サイズの配列を含む構造体：ffi.new（'int []', 42）の長さを常に追跡していたのと同様に、ffi.new（）の呼び出し後に配列の長さを追跡するようになりました。これにより、配列項目への範囲外アクセスを検出できます。また、より適切なrepr（）を表示できるようになり、ffi.sizeof（）とffi.buffer（）から合計サイズが返されます。以前は、両方の関数が、宣言された構造体型のサイズに基づいて、空の配列を想定した結果を返していました。（このリファクタリングを開始してくれたandrewに感謝の意を表します。）

型定義：typedef int foo_t [...];内の詳細不明な長さの配列に対するcdef（）/set_source（）のサポートを追加します。これは、グローバル変数または構造フィールドですでにサポートされています。

v1.8では、cffi/model.pyからの警告がエラーになりました：'enum xxx'には明示的に定義された値が格納されません：どの整数型であるか（符号なし/符号付き、int/long）の推測に対する拒否。再び警告に戻しました。列挙型のサイズがintであると推測するのは、99%確実なことのようです。（ただし、100％ではないため、警告に留まります。）

FILE *引数を処理するコードの漏洩を修正します。CPython 3には、修正が困難な問題が残っています：PythonファイルオブジェクトをFILE *引数に渡す場合は、os.dup（）が使用され、close（）（オリジナルのファイル記述子のみを閉じる）を呼び出したときではなく、GCがPythonファイルオブジェクトを再要求したときだけ、新しいファイル記述子が閉じられます。これが問題になる場合は、このPythonファイルオブジェクトの自動変換を回避する必要があります：代わりに、ファイル記述子を明示的に操作し、Cからfdopen（）を呼び出してください（cffi経由）。

異なるポインター型を持つ関数にvoid *引数を渡すと（またはその逆の場合）、Cの場合のようにキャストが自動的に行われます。ffi.new（）とその他のいくつかの場所での初期化でも同じことが起こります。
ただし、char *にも同じ特性があると思っていましたが、誤りでした。Cでは、たとえば、char **引数にchar *を入力しようとすると、通常の警告が表示されます。混乱させたことをお詫びします。現在は、CFFI内で警告も表示することによって修正されています。将来のバージョンでエラーにする予定です。

問題#283：混合内に少なくとも1つのユニオンが入っている場合の、ネスト化された匿名の構造体/ユニオンを含む構造体/ユニオンに対するffi.new（）を修正しました。listまたはdictを使用して初期化された場合は、GCC内の{}構文のようにより厳密に動作するはずです。

CPython 3.x：experimental：生成されたC拡張モジュールで、「制限付きAPI」が使用されるようになりました。つまり、コンパイルされた.so/.dllとして、3.2以降の任意のバージョンのCPythonで直接動作するはずです。distutilsによって生成される名前は、依然としてバージョン固有のものです。バージョンに依存しない名前を取得するには、手動でNAME.abi3.soに名前を変更するか、最新のsetuptools 26を使用します

python setup.py build --debugに似たffi.compile（debug=...）を追加しましたが、デバッグバージョンのPython自体を実行している場合はデフォルトでTrueに設定されます。

ffi.from_buffer（）はバイト文字列に対して使用できないという制限を削除しました。バイト文字列からchar *を取得できるようになりました。これは、文字列オブジェクトが稼働している限り有効です。（ただし、文字列オブジェクトの修正には使用しないでください！これが必要な場合は、bytearrayまたはその他の公式の手法を使用してください。）

PyPy 5.4で、バイト文字列をchar *引数に直接渡すことができるようになりました（古いバージョンでは、コピーが作成されます）。以前は、CPython専用の最適化でした。

ffi.gc（p, None）が、ffi.gc（）に対する別の呼び出しで以前に作成されたオブジェクトのデストラクターを削除します

bool（ffi.cast（'primitive type', x））が、値が0（-0.0を含む）の場合はFalseを、それ以外の場合はTrueを返すようになりました。以前は、ポインターがNULLの場合に、ポインター型のcdataオブジェクトに対してのみFalseを返していました。

bytearrays：ffi.from_buffer（bytearray-object）がサポートされるようになりました。（サポートされていなかった理由は、PyPyで行うのが難しかったためですが、PyPy 5.3以降では動作します。）バッファオブジェクト（現在はbytearrayを含む）からchar *引数でC関数を呼び出すには、「lib.foo（ffi.from_buffer（x））」と記述します。加えて、これがサポートされるようになりました：
p[0：length] = bytearray-object。これに伴う問題は、bytearrayを反復すると、文字ではなく数字が入力されることでした。（現在は、実際に文字を反復するのではなく、memcpyだけで実装されています。）

C++：生成されたCコードをC ++でコンパイルすることは可能と考えられていましたが、bool型を使用すると失敗します（これは、C++には存在しないC _Bool型としてレンダリングされるためです）。

help（lib）とhelp（lib.myfunc）が、pが構造体または構造体へのポインターの場合に、dir（p）に加えて、有益な情報を提供するようになりました。

適切な場所でのビットシフトをビット単位と自分自身との比較に置き換えることにより、「負の左シフト」警告を修正しました。upstream gitから取得されたパッチ。cffi-1.5.2-wnoerror.patchをドロップします：必要なくなりました。

upstreamで問題の未定義コードが修正されるまで、gcc6の失敗を防ぐためにテストスイート内の「負の左シフト」警告を無効にします（bsc#981848）

バージョン1.6.0への更新：ffi.list_types（）

ffi.unpack（）

extern 'Python+C';

APIモードでは、lib.foo.__doc__にC署名が含まれるようになりました。

CPythonのインタープリターシャットダウンのロジックに対するffi.def_extern（）の堅牢性への別の試み。

1.5.2 に更新：cffiベースの埋め込みをサポートします

シャットダウンロジックの堅牢性を向上させます

python-cryptographyを2.1.4に更新しました（bsc#1138748、jsc#ECO-1256、jsc#PM-1598）このバージョンのパッケージをOpenSSL 1.1.1dと互換にします（bsc#1149792）

CVE-2018-10903：finalize_with_tag API内の切り捨てられたタグを介したGCMタグの偽造を修正しました（bsc#1101820）

バージョン2.1.4への更新：次回のpyOpenSSLリリースのためにX509_up_refを追加しました。

OpenSSLのスタックが実行可能とマークされるmanylinux1ホイールに伴うバグを修正しました。

OpenSSL 1.0.0のサポートが削除されました。

ディフィー・ヘルマンキー交換のサポートを追加しました

OpenSSL用のOSランダムエンジンが書き換えられました

python-xattrがcffiの依存関係を調整するために再ビルドされました。

注意：Tenable Network Securityは、前述の記述ブロックをSUSEセキュリティアドバイザリから直接抽出しています。Tenableでは、そこに新しい問題を追加することはせずに、できる限り自動的に整理と書式設定をするようにしています。

python-cryptography用のこの更新プログラムでは、以下の問題が修正されています：

  - CVE-2018-10903：finalize_with_tag APIでは、最小タグ長が強制的に適用されませんでした。ユーザーが入力をfinalize_with_tagに渡す前にその長さを検証しない場合、攻撃者が、MACチェックをパスする可能性が256分の1になるように、短縮タグ（1バイトなど）を使って無効なペイロードを細工する可能性があります。GCMタグの偽造により、鍵の漏洩が引き起こされる可能性があります（bsc#1101820）。

この更新プログラムはSUSEからインポートされました：SLE-15：更新プロジェクトを更新します。

リモート Redhat Enterprise Linux 7 ホストに、RHSA-2018:3600 アドバイザリに記載されている脆弱性の影響を受けるパッケージがインストールされています。

  - python-cryptography: finalize_with_tag API 内の切り捨てられたタグを介した GCMタグの偽造 (CVE-2018-10903)

Nessus はこの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

python-cryptography用のこの更新プログラムでは、以下の問題が修正されています：

  - CVE-2018-10903：finalize_with_tag APIでは、最小タグ長が強制的に適用されませんでした。ユーザーが入力をfinalize_with_tagに渡す前にその長さを検証しない場合、攻撃者が、MACチェックをパスする可能性が256分の1になるように、短縮タグ（1バイトなど）を使って無効なペイロードを細工する可能性があります。GCMタグの偽造により、鍵の漏洩が引き起こされる可能性があります（bsc#1101820）。

この更新はSUSEからインポートされました：SLE-15：更新プロジェクトを更新します。

このpython-cffi、python-cryptographyの更新では、次の問題を修正します：

修正されたセキュリティ問題：

CVE-2018-10903：finalize_with_tag API内の切り捨てられたタグを介したGCMタグの偽造を修正しました（bsc#1101820）。

修正された非セキュリティ問題：

python-cffiが1.11.2に更新しました （bsc#1138748、jsc#ECO-1256、jsc#PM-1598）：i586上のビルドの失敗を修正しました（bsc#1111657）

ソルトはスナップショット20171129でハイ状態にできませんでした（bsc#1070737）

spec内のpytestを更新して、testingディレクトリに加えてcディレクトリtestsを追加します。

バージョン1.11.2への更新：

  - CPython 3.0〜3.5上のスレッド状態の管理に伴うWindowsの問題を修正します

spec内のpytestを更新して、testingディレクトリに加えてcディレクトリtestsを追加します。

指定された時間内に終了する複数のスレッドに依存するため、test_init_once_multithreadテストを省略します。ビルド内で散発的な合否を返します。

1.11.1への更新：

  - テストを修正し、廃止されたC APIの使用を削除します

  - 互換性のないバイナリ拡張を提供する3.6.0/3.6.1/3.6.2を修正（解決）します（cpython問題#29943）

  - 3.7.0a1+を修正します

1.11.0への更新：

  - 最新の標準型のchar16_tとchar32_tをサポートします。
    これらは、wchar_tと同様に機能します：1つのunicode文字を表したり、charN_t *またはcharN_t[]として使用された場合は、unicode文字列を表します。wchar_tとの違いは、既知の固定サイズであることです。wchar_tで機能していたすべての場所で機能するはずです（見落としがあれば、問題を報告してください）。set_source（）では、これらの型が指定したCソースで実際に定義されていることを確認する必要があることに注意してください（cdef（）内で使用した場合）。

  - C99型のfloat_Complexとdouble
    _Complexをサポートします。libffiはこれらをサポートしていないことに注意してください。これは、ABIモードでは、引き続き、引数や戻り値の型として直接複素数を取るC関数を呼び出すことができないことを意味しています。

  - 複数のスレッドから複数のFFIインスタンスが作成された場合の稀な競合状態を修正しました。（多数のFFIインスタンスを作成するわけではありません：インラインモードでは、import cffiの直後にモジュールレベルでffi = cffi.FFI（）を記述する必要があります。また、out-of-lineモードでは、FFIを明示的にインスタンス化しません）

  - Windows：CFFI内部エラーメッセージがstderrに出力されるにもかかわらず、stderrが多くのアプリケーションでどこにも表示されないため、コールバックの使用が煩雑になる可能性があります。そのため、埋め込みモードで開始することが特に困難になります。（使い始めると、少なくとも@ffi.def_extern（onerror=...）を使用して、アプリケーションに意味のあるエラーログを送信したり、ログファイルに記録したりできます）。CFFIで新しい点は、Windowsで、CFFIが（rawメッセージをstderrに送信することに加えて）非モーダルMessageBoxを開こうとすることです。MessageBoxは、プロセスが稼働している間だけ表示されます：通常、クラッシュしたコンソールアプリケーションはすぐに終了しますが、stderrをとにかく表示すべき状況でもあります。

  - NetBSDでのコールバックのサポートの進捗。

  - ブール値を返す関数が、FalseまたはTrueの代わりに0または1を返す場合があります。修正しました。

  - ffi.gc（）は、オブジェクトのサイズ（バイト単位）の推定値を提供するオプションの第3パラメーターを取るようになりました。
    現時点では、次のGCをより素早く発生させるために、PyPyによってのみ使用されます（問題#320）。将来的には、CPythonにも影響を与える可能性があります（CPython問題31105が解決された場合）。

  - ドキュメントに注記を追加します：ABIモードでは、APIモードよりも呼び出しが遅い関数オブジェクトが提供されます。何らかの理由で、もっと高速であると見なされているようですが、それは違います！

1.10.1への更新：

  - cdef（）エラーの場合に報告される行番号を修正しました。今気付いたのですが、pycparserは、常に、プリプロセッサーディレクティブの#42 'foo.h'をサポートしていました。これは、「次の行から、foo.hファイルの42行目が始まる」という意味で、これがエラーメッセージに入っています。

1.10.0 への更新：

  - 問題#295：PyObject_Malloc（）+memset（）の代わりにcalloc（）を直接使用して、デフォルトのアロケーターでffi.new（）を処理するようにします。ほとんどの配列を操作しないことでffi.new（large-array）を高速化します。

  - 一部のOS/Xビルドの修正（「Xcodeのみを使用してCLTを使用しない」）。

  - いくつかのエラーメッセージを改善します：cffiとそのバックエンドのバージョンが一致しない場合や引数が「複雑すぎる」（しかも、常に機能する構造体ポインターではない）構造体であるためにlibffiを使用して呼び出すことができない関数を呼び出す場合。

  - 一部のあまり使用されないコンパイラ（non-msvc、non-gcc、non-icc、non-clang）のサポートを追加します

  - ffi.from_bufferの残りのケースを実装しました。すべてのbuffer/memoryviewオブジェクトを渡すことができるようになりました。残っている1つのチェックは、Python 2でのunicode文字列の受け渡しに対するものです（これらはバッファインターフェイスをサポートしますが、大抵は想定外のUTF16/UCS4ストレージの背後にrawバイトを提供します。Python 3では、これが修正され、unicode文字列でmemoryviewインターフェイスがサポートされなくなりました）。

  - C型の_Boolまたはboolが、読み取り時に、整数としてのバイトの内容ではなく、Pythonブール値に変換されるようになりました。ここでの潜在的な非互換性は、バイトに0や1とは異なる値が含まれている場合に発生するものです。以前は、その値を返すだけでした。この変更により、CFFIがこのケースで例外を発生させます。ただし、このケースはCにおける「未定義の動作」を意味します。これに依存するライブラリとのインターフェイスが本当に必要な場合は、CFFI側でboolを使用しないでください。また、bool[]の初期化子としてバイト文字列を使用することは今でも有効ですが、\x00または\x01のみを含める必要があります。余談として、ffi.string（）がbool[]で動作しなくなりました（ただし、この関数は最初の0で停止するため、効果はありません）。

  - ffi.bufferはcffiのバッファタイプの名前になり、ffi.buffer（）は以前と同様に動作しますが、そのタイプのコンストラクターになりました。

  - ffi.addressof（lib, 'name'）が、out-of-lineモードだけでなく、インラインモードでも動作するようになりました。これは、グローバル変数のアドレスを取得するのに便利です。

  - 問題#255：プリミティブ型のcdataオブジェクト（整数、浮動小数、文字）が比較され、値で順序付けられるようになりました。たとえば、 <cdata>は42に等しいかを比較し、<cdata b>はb'A'に等しいかを比較します。Cとは異なり、<cdata> はffi.cast（ 'unsigned int'、-1）と等しいを比較しません：より小さいかを比較します。これは、-1</cdata></cdata></cdata>

が、Sphinxの間接的な依存関係であるパッケージに関するHTMLドキュメントを生成しないためです（https://cffi.readthedocs.org/にあるドキュメントを参照してください）

1.9.1への更新

  - 最終フィールドとして可変サイズの配列を含む構造体：
    ffi.new（'int []', 42）の長さを常に追跡していたのと同様に、ffi.new（）の呼び出し後に配列の長さを追跡するようになりました。これにより、配列項目への範囲外アクセスを検出できます。また、より適切なrepr（）を表示できるようになり、ffi.sizeof（）とffi.buffer（）から合計サイズが返されます。以前は、両方の関数が、宣言された構造体型のサイズに基づいて、空の配列を想定した結果を返していました。（このリファクタリングを開始してくれたandrewに感謝の意を表します。）

  - 型定義：typedef int foo_t [...];内の詳細不明な長さの配列に対するcdef（）/set_source（）のサポートを追加します。これは、グローバル変数または構造フィールドですでにサポートされています。

  - v1.8では、cffi/model.pyからの警告がエラーになりました：'enum xxx'には明示的に定義された値が格納されません：
    どの整数型であるか（符号なし/符号付き、int/long）の推測に対する拒否。再び警告に戻しました。列挙型のサイズがintであると推測するのは、99%確実なことのようです。（ただし、100％ではないため、警告に留まります。）

  - FILE *引数を処理するコードの漏洩を修正します。CPython 3には、修正が困難な問題が残っています：PythonファイルオブジェクトをFILE *引数に渡す場合は、os.dup（）が使用され、close（）（オリジナルのファイル記述子のみを閉じる）を呼び出したときではなく、GCがPythonファイルオブジェクトを再要求したときだけ、新しいファイル記述子が閉じられます。これが問題になる場合は、このPythonファイルオブジェクトの自動変換を回避する必要があります：代わりに、ファイル記述子を明示的に操作し、Cからfdopen（）を呼び出してください（cffi経由）。

  - 異なるポインター型を持つ関数にvoid *引数を渡すと（またはその逆の場合）、Cの場合のようにキャストが自動的に行われます。ffi.new（）とその他のいくつかの場所での初期化でも同じことが起こります。
    ただし、char *にも同じ特性があると思っていましたが、誤りでした。Cでは、たとえば、char **引数にchar *を入力しようとすると、通常の警告が表示されます。
    混乱させたことをお詫びします。現在は、CFFI内で警告も表示することで修正されています。将来のバージョンでエラーにする予定です。

  - 問題#283：混合内に少なくとも1つのユニオンが入っている場合の、ネスト化された匿名の構造体/ユニオンを含む構造体/ユニオンに対するffi.new（）を修正しました。listまたはdictを使用して初期化された場合は、GCC内の{}構文のようにより厳密に動作するはずです。

  - CPython 3.x：experimental：生成されたC拡張モジュールで、「制限付きAPI」が使用されるようになりました。つまり、コンパイルされた.so/.dllとして、3.2以降の任意のバージョンのCPythonで直接動作するはずです。distutilsによって生成される名前は、依然としてバージョン固有のものです。バージョンに依存しない名前を取得するには、手動でNAME.abi3.soに名前を変更するか、最新のsetuptools 26を使用します

  - python setup.py build --debugに似たffi.compile（debug=...）を追加しましたが、デバッグバージョンのPython自体を実行している場合はデフォルトでTrueに設定されます。

  - ffi.from_buffer（）はバイト文字列に対して使用できないという制限を削除しました。バイト文字列からchar *を取得できるようになりました。これは、文字列オブジェクトが稼働している限り有効です。（ただし、文字列オブジェクトの修正には使用しないでください！これが必要な場合は、bytearrayまたはその他の公式の手法を使用してください。）

  - PyPy 5.4で、バイト文字列をchar *引数に直接渡すことができるようになりました（古いバージョンでは、コピーが作成されます）。以前は、CPython専用の最適化でした。

  - ffi.gc（p, None）が、ffi.gc（）に対する別の呼び出しで以前に作成されたオブジェクトのデストラクターを削除します

  - bool（ffi.cast（'primitive type', x））が、値が0（-0.0を含む）の場合はFalseを、それ以外の場合はTrueを返すようになりました。
    以前は、ポインターがNULLの場合に、ポインター型のcdataオブジェクトに対してのみFalseを返していました。

  - bytearrays：ffi.from_buffer（bytearray-object）がサポートされるようになりました。（サポートされていなかった理由は、PyPyで行うのが難しかったためですが、PyPy 5.3以降では動作します。）バッファオブジェクト（現在はbytearrayを含む）からchar *引数でC関数を呼び出すには、「lib.foo（ffi.from_buffer（x））」と記述します。加えて、これがサポートされるようになりました：p[0：length] = bytearray-object。これに伴う問題は、bytearrayを反復すると、文字ではなく数字が入力されることでした。（現在は、実際に文字を反復するのではなく、memcpyだけで実装されています。）

  - C++：生成されたCコードをC ++でコンパイルすることは可能と考えられていましたが、bool型を使用すると失敗します（これは、C++には存在しないC _Bool型としてレンダリングされるためです）。

  - help（lib）とhelp（lib.myfunc）が、pが構造体または構造体へのポインターの場合に、dir（p）に加えて、有益な情報を提供するようになりました。

multipythonビルドの更新

upstreamで問題の未定義コードが修正されるまで、gcc6の失敗を防ぐためにテストスイート内の「負の左シフト」警告を無効にします（bsc#981848）

バージョン 1.6.0 に更新してください：

  - ffi.list_types（）

  - ffi.unpack（）

  - extern 'Python+C';

  - APIモードでは、lib.foo.__doc__にC署名が含まれるようになりました。

  - CPythonのインタープリターシャットダウンのロジックに対するffi.def_extern（）の堅牢性への別の試み。

SLE-12での更新（bsc#1138748、jsc#ECO-1256、jsc#PM-1598）

このバージョンのパッケージをOpenSSL 1.1.1dと互換にして bsc#1149792を修正します。

finalize_with_tag API内の切り捨てられたタグを介したbsc#1101820 CVE-2018-10903 GCMタグの偽造

python2に適切な条件を追加します。ifpythonは、requires/etcに対してのみ機能します

python sslで欠如していた依存関係を追加します

バージョン2.1.4への更新：

  - 次回のpyOpenSSLリリースのためにX509_up_refを追加しました。

バージョン2.1.3への更新：

  - Windows、macOS、およびmanylinux1のホイールを更新し、OpenSSL 1.1.0gでコンパイルできるようにしました。

バージョン2.1.2への更新：

  - OpenSSLのスタックが実行可能とマークされるmanylinux1ホイールに伴うバグを修正しました。

python3のBuildRequires条件を修正します

2.1.1への更新

cffiバージョンの要件を修正します。

memleakテストを無効にして、OpenSSL 1.1でのビルドを修正します（bsc#1055478）

2.0.3への更新

2.0.2への更新

2.0への更新

1.9への更新

setuptoolsに依存する代わりに、要件にpython-packagingを明示的に追加して配置します

singlespecアプローチに切り替えます

1.8.1への更新

RequiresとBuildRequiresを調整します

注意：Tenable Network Securityは、前述の記述ブロックをSUSEセキュリティアドバイザリから直接抽出しています。Tenableでは、そこに新しい問題を追加することはせずに、できる限り自動的に整理と書式設定をするようにしています。

リモートの SUSE Linux SLED15 / SLES15 / openSUSE 15 ホストには、SUSE-SU-2022:4044-1 のアドバイザリに記載されている脆弱性の影響を受けるパッケージがインストールされています。

  - python-cryptography 2.3 以降 1.9.0 より前のバージョンに欠陥が見つかりました。finalize_with_tag APIでは、最小タグ長が強制的に適用されませんでした。ユーザーが入力をfinalize_with_tagに渡す前にその長さを検証しない場合、攻撃者が、MACチェックをパスする可能性が256分の1になるように、短縮タグ（1バイトなど）を使って無効なペイロードを細工する可能性があります。GCM タグの偽造により、鍵の漏洩が引き起こされる可能性があります。
    (CVE-2018-10903)

Nessus はこの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

python-cryptographyが特定の入力を不適切に処理することが発見されました。攻撃者はこれを利用して、秘密情報にアクセスする可能性があります。

注意: Tenable Network Security は、前述の説明ブロックを Ubuntu セキュリティアドバイザリからすでに直接抽出しています。Tenable では、新たな問題を持ち込まずに、できる限り自動的に整理して書式設定するようにしています。

Python Cryptographic Authority（PyCA）プロジェクトによる報告:

finalize_with_tag()はデフォルトでタグの切り捨てを許可していました。これにより、場合によってはタグの偽造が可能になることがあります。このメソッドは、GCMコンストラクターに提供されるmin_tag_lengthを強制するようになりました

python-cryptography用のこの更新プログラムでは、以下の問題が修正されています：

CVE-2018-10903：finalize_with_tag APIでは、最小タグ長が強制的に適用されませんでした。ユーザーが入力をfinalize_with_tagに渡す前にその長さを検証しない場合、攻撃者が、MACチェックをパスする可能性が256分の1になるように、短縮タグ（1バイトなど）を使って無効なペイロードを細工する可能性があります。GCMタグの偽造により、鍵の漏洩が引き起こされる可能性があります（bsc#1101820）。

注意：Tenable Network Securityは、前述の記述ブロックをSUSEセキュリティアドバイザリから直接抽出しています。Tenableでは、そこに新しい問題を追加することはせずに、できる限り自動的に整理と書式設定をするようにしています。

ID	名前	製品	ファミリー	公開日	更新日	深刻度
134937	SUSE SLES12セキュリティ更新プログラム：python-cffi、python-cryptography、python-xattr（SUSE-SU-2020:0790-1）	Nessus	SuSE Local Security Checks	2020/3/26	2024/3/20	high
118451	openSUSEセキュリティ更新プログラム：python-cryptography（openSUSE-2018-1281）	Nessus	SuSE Local Security Checks	2018/10/26	2024/7/29	high
194135	RHEL 7 : python-cryptography (RHSA-2018:3600)	Nessus	Red Hat Local Security Checks	2024/4/27	2024/6/3	high
123358	openSUSEセキュリティ更新プログラム：python-cryptography（openSUSE-2019-857）	Nessus	SuSE Local Security Checks	2019/3/27	2024/6/10	high
134938	SUSE SLES12セキュリティ更新プログラム：python-cffi、python-cryptography（SUSE-SU-2020:0792-1）	Nessus	SuSE Local Security Checks	2020/3/26	2024/3/20	high
167941	SUSE SLED15 / SLES15 / openSUSE 15 セキュリティ更新: python-cryptography、python-cryptography-vectors (SUSE-SU-2022:4044-1)	Nessus	SuSE Local Security Checks	2022/11/19	2023/7/14	high
111269	Ubuntu 18.04 LTS : python-cryptographyの脆弱性 (USN-3720-1)	Nessus	Ubuntu Local Security Checks	2018/7/24	2024/8/27	high
111541	FreeBSD: py-cryptography -- タグ偽造の脆弱性（9e2d0dcf-9926-11e8-a92d-0050562a4d7b）	Nessus	FreeBSD Local Security Checks	2018/8/6	2024/8/27	high
120144	SUSE SLED15 / SLES15セキュリティ更新プログラム：python-cryptography（SUSE-SU-2018:3392-1）	Nessus	SuSE Local Security Checks	2019/1/2	2024/7/10	high

検出

プラグインの検索

high

high

high

high

high

high

high

high

high