Comment 14 for bug 1430082

I reviewed python-cryptography version 0.8-1ubuntu2 as checked into Ubuntu
vivid. This shouldn't be considered a full security audit but rather a
quick gauge of maintainability.

- python-cryptography provides a cffi interface to OpenSSL with friendly
  shims for better python integration
- Build-Depends: debhelper, dh-python, python-all-dev, python3-all-dev,
  python-setuptools, python3-setuptools, python-cffi, python3-cffi,
  python-six, python3-six, libssl-dev, python-cryptography-vectors,
  python-cryptography-vectors, python3-cryptography-vectors,
  python3-cryptography-vectors, python-iso8601, python3-iso8601,
  python-pytest, python3-pytest, python-pretend, python3-pretend,
  python-pyasn1, python3-pyasn1, python-enum34, python3-enum34
- This package provides both recipes for safe cryptography use as well as
  a hazmat namespace for raw cryptography use. This package does not
  itself daemonize or connect to the network.
- pre/post inst/rm scripts automatically generated
- No initscripts
- No dbus services
- No binaries in the path
- No setuid or setgid
- No sudo fragments
- No udev rules
- No cronjobs
- Extensive test suite with thousands of test cases run during the build
- Clean build logs

- No subprocesses are spawned
- Memory management is very complicated; Python modules implemented in C
  need to manage both the python-GC system and the C unmanaged memory
  allocations. There were instructive comments near some C implementations
  about the proper way to manage that object type's memory, but errors
  feel inevitable.
- Very few file operations itself
- Logging looked safe
- No environment variable use on Linux, looked safe on Windows
- No privileged portions of code
- Extensive cryptography, much under control of client programs
- No networking
- No temporary file handling
- No WebKit
- No javascript
- No PolicyKit

python-cryptography is intricate, involved code; Python modules and
cffi are complicated, and OpenSSL's API is dangerous at the best of
times. That said, this code looks careful -- there's good parameter
checking, asserts throughout, comments are descriptive where they are
used, documentation is good.

I did not extensively check the cryptography used; spot checks looked
fine, Fernets looked interesting.

Security team ACK for promoting python-cryptography to main.

Thanks