This update for python-cffi, python-cryptography and python-xattr fixes the following issues:
Security issue fixed:
- CVE-2018-10903: Fixed GCM tag forgery via truncated tag in finalize_with_tag API (bsc#1101820).
Non-security issues fixed:
python-cffi was updated to 1.11.2 (bsc#1138748, jsc#ECO-1256, jsc#PM-1598):
-
fixed a build failure on i586 (bsc#1111657)
-
Salt was unable to highstate in snapshot 20171129 (bsc#1070737)
-
Update pytest in spec to add c directory tests in addition to
testing directory.
Update to 1.11.1:
- Fix tests, remove deprecated C API usage
- Fix (hack) for 3.6.0/3.6.1/3.6.2 giving incompatible binary
extensions (cpython issue #29943)
- Fix for 3.7.0a1+
Update to 1.11.0:
- Support the modern standard types char16_t and char32_t. These
work like wchar_t: they represent one unicode character, or when
used as charN_t * or charN_t[] they represent a unicode string.
The difference with wchar_t is that they have a known, fixed
size. They should work at all places that used to work with
wchar_t (please report an issue if I missed something). Note
that with set_source(), you need to make sure that these types
are actually defined by the C source you provide (if used in
cdef()).
- Support the C99 types float _Complex and double _Complex. Note
that libffi doesn't support them, which means that in the ABI
mode you still cannot call C functions that take complex
numbers directly as arguments or return type.
- Fixed a rare race condition when creating multiple FFI instances
from multiple threads. (Note that you aren't meant to create
many FFI instances: in inline mode, you should write
ffi = cffi.FFI() at module level just after import cffi; and in
out-of-line mode you don't instantiate FFI explicitly at all.)
- Windows: using callbacks can be messy because the CFFI internal
error messages show up to stderr-but stderr goes nowhere in many
applications. This makes it particularly hard to get started...