Comment 14 for bug 1630073

I reviewed python-pyelftools version 0.24-3 as checked into Debian
unstable. This shouldn't be considered a full security audit but rather a
quick gauge of maintainability.

- No CVEs in our database
- python-pyelftools provides a Python API for inspecting ELF objects
  without dependencies upon readelf or binutils

- Build-Depends: debhelper), dh-python, python, python3
- No cryptography
- No networking
- Does not damonize
- automatically generated pre/post inst/rm scripts
- No initscripts
- No dbus services
- No setuid files
- No binaries in PATH
- No sudo fragments
- No udev rules
- Test suite run during package build
- No cronjobs
- Clean build logs

- subprocesses only spawned in test suite, looked good
- Files only manipulated in test suite, looked good
- Almost all logging is in the test suite, looked good
- No environment use
- No privileged functions
- No networking
- No cryptography
- No privileged portions of code
- Temp files only handled in test suite, looked good
- No webkit
- No javascript
- No policykit

ELF files are complicated enough that parsing them has been a frequent
source of security issues in the Linux kernel, binutils, readelf, and
doubtless many other tools. So while a re-implementation of ELF parsing is
bound to reintroduce some of the same bugs already solved elsewhere, the
memory safety of Python means the consequences are probably less severe
than other implementations.

There's one very dangerous idiom used in some of the examples:

- examples load . and .. into sys.path
- scripts/readelf.py loads . into sys.path

This is fine for software that's obviously examples but these examples
look useful enough that they may some day be promoted to 'real tools'.

These tools must not be promoted with the sys.path manipulations in place.

Security team ACK for promoting python-pyelftools to main.

Thanks