[MIR] python-cryptography, python-cffi, pycparser, enum34

[Steve Langasek]

[Background information]

pyopenssl 0.14 has rewritten custom python C extension binding to using cffi interface to openssl.

At the same time the upstream packages have been split - thus pyopenssl is purepython now, but depends on python-cryptography -> python-cffi -> pycparser to build & run.

pyopenssl is in main already.

python-cryptography packaging has been tweaked to drop test only dependency, and move them to autopackagetests alone. Such that we don't need to MIR all of those. (E.g. pypy and friends). Thus the test suite is executed as an autopackage test only, rather than at build time.

[Availability]
pycparser & python-cffi are in universe

[Rationale]
to keep pyopenssl, which is required for ubuntu-sso-client and OpenStack clients in main.

[Security]
Dangerous crypto-facing code...

[Quality assurance]
Testsuite present and enforced via autopackagetests.

[Dependencies]
These are the dependencies:
pycparser, python-cffi, python-cryptography

[Standards compliance]
Gains TLS 1.1 & 1.2 support in pyopenssl

[Maintenance]
Server/Cloud Teams ?

[Steve Langasek (vorlon)]

Dimitri, this was a manual sync of pyopenssl by you. Could you please follow through on the MIR to get its dependencies into main?

[Steve Langasek (vorlon)]

(dependency details at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg)

[Dimitri John Ledkov (xnox)]

meh, that looks horrible. And we don't want pypy in main just yet =(

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-cryptography - 0.6.1-1ubuntu1

---------------
python-cryptography (0.6.1-1ubuntu1) vivid; urgency=medium

  * Do not run build time test-suite, due to test requirements in
    universe, instead add them to debian/tests/control and rely on
    autopackagetests alone. Autopackage tests are enforcing
    gatekeeper. (LP: #1430082)
 -- Dimitri John Ledkov <email address hidden> Wed, 11 Mar 2015 22:44:59 +0000

[Matthias Klose (doko)]

I don't like the way that python-cryptography is dropping the tests. python-cryptography-vectors is just used for the tests, and contains test data. I'll look at python-pretend myself for the MIR and for not building pypy-pretend.

[Barry Warsaw (barry)]

For enum34:

[Availability]
In universe since Trusty.

[Rationale]
Used by some packages that want enum support in older Python versions. Used by python-cryptography (another package in this MIR).

[Security]
No known security issues. None to be expected really, since it only provides a basic data type.

[Quality assurance]
Bugs are well tracked upstream. Code is well tested in upstream Python.

[Dependencies]
None other than Python itself.

[Standards compliance]
Meets Debian and Debian Python standards.

[Maintenance]
Package is well maintained upstream by Python's enum stdlib maintainer, and in Debian by the DPMT and myself.

[Background information]
enum34 is a standalone version of the Python 3.4 stdlib enum package. It's compatible with older Python 3 and Python 2 versions and is often used to provide cross-version compatibility in packages that want to use enums in older Python versions.

[James Page (james-page)]

+1'ing this MIR for OpenStack Kilo on vivid as well

Keystone has introduced a new token format requiring python-cryptography and python-glance-store needs enum34.

[Matthias Klose (doko)]

python-pretend is a 3k module providing stubbing for test writers. Looks good to me, no open bug reports, both Debian and upstream.

Override component to main
python-pretend 1.0.8-1ubuntu1 in vivid: universe/misc -> main
python-pretend 1.0.8-1ubuntu1 in vivid amd64: universe/python/optional/100% -> main
python-pretend 1.0.8-1ubuntu1 in vivid arm64: universe/python/optional/100% -> main
python-pretend 1.0.8-1ubuntu1 in vivid armhf: universe/python/optional/100% -> main
python-pretend 1.0.8-1ubuntu1 in vivid i386: universe/python/optional/100% -> main
python-pretend 1.0.8-1ubuntu1 in vivid powerpc: universe/python/optional/100% -> main
python-pretend 1.0.8-1ubuntu1 in vivid ppc64el: universe/python/optional/100% -> main
python3-pretend 1.0.8-1ubuntu1 in vivid amd64: universe/python/optional/100% -> main
python3-pretend 1.0.8-1ubuntu1 in vivid arm64: universe/python/optional/100% -> main
python3-pretend 1.0.8-1ubuntu1 in vivid armhf: universe/python/optional/100% -> main
python3-pretend 1.0.8-1ubuntu1 in vivid i386: universe/python/optional/100% -> main
python3-pretend 1.0.8-1ubuntu1 in vivid powerpc: universe/python/optional/100% -> main
python3-pretend 1.0.8-1ubuntu1 in vivid ppc64el: universe/python/optional/100% -> main
13 publications overridden.

[Matthias Klose (doko)]

ok, looks good.

Override component to main
enum34 1.0.3-1 in vivid: universe/misc -> main
python-enum34 1.0.3-1 in vivid amd64: universe/python/optional/100% -> main
python-enum34 1.0.3-1 in vivid arm64: universe/python/optional/100% -> main
python-enum34 1.0.3-1 in vivid armhf: universe/python/optional/100% -> main
python-enum34 1.0.3-1 in vivid i386: universe/python/optional/100% -> main
python-enum34 1.0.3-1 in vivid powerpc: universe/python/optional/100% -> main
python-enum34 1.0.3-1 in vivid ppc64el: universe/python/optional/100% -> main
python-enum34-doc 1.0.3-1 in vivid amd64: universe/doc/optional/100% -> main
python-enum34-doc 1.0.3-1 in vivid arm64: universe/doc/optional/100% -> main
python-enum34-doc 1.0.3-1 in vivid armhf: universe/doc/optional/100% -> main
python-enum34-doc 1.0.3-1 in vivid i386: universe/doc/optional/100% -> main
python-enum34-doc 1.0.3-1 in vivid powerpc: universe/doc/optional/100% -> main
python-enum34-doc 1.0.3-1 in vivid ppc64el: universe/doc/optional/100% -> main
python3-enum34 1.0.3-1 in vivid amd64: universe/python/optional/100% -> main
python3-enum34 1.0.3-1 in vivid arm64: universe/python/optional/100% -> main
python3-enum34 1.0.3-1 in vivid armhf: universe/python/optional/100% -> main
python3-enum34 1.0.3-1 in vivid i386: universe/python/optional/100% -> main
python3-enum34 1.0.3-1 in vivid powerpc: universe/python/optional/100% -> main
python3-enum34 1.0.3-1 in vivid ppc64el: universe/python/optional/100% -> main
19 publications overridden.

[Matthias Klose (doko)]

python-cffi / pycparser:

The packaging looks sane, well maintained in Debian, and upstream. No bug reports in Debian and Ubuntu. From my point of view these two packages are fine, except for one odd thing, now documented in LP: #1442369, and suggesting that the python-cffi package is split into a python-cffi-runtime package and a python-cffi package. Unsure if that should be a blocker for the migration to main.

[Michael Terry (mterry)]

Yeah, agreed that python-cffi and pycparser seem fine. They need team bug subscribers though.

[James Page (james-page)]

Added ubuntu-server as team bug subscriber for pycparser and python-cffi.

[James Page (james-page)]

Ditto python-cryptography*

[Seth Arnold (seth-arnold)]

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

[Michael Terry (mterry)]

python-cryptography looks fine to me too. Approved.

[Seth Arnold (seth-arnold)]

python-cryptography-vectors is as described -- an impressive collection of test vectors. The only slightly surprising thing is the pre/post inst/rm scripts, due to this being part of a python module package.

Security team ACK for promoting python-cryptography-vectors to main, though I suspect we don't strictly need the binary packages themselves in main. Either way, doesn't really matter.

Thanks

[Adam Conrad (adconrad)]

Approved -vectors, and promoted along with the others.