I reviewed x265 3.5-2 as checked into lunar. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

Upstream: https://bitbucket.org/multicoreware/x265_git/wiki/Home

x265 is an opensource H.265/HEVC encoder, aiming to provide
the highest compression efficiency at the highest performance.

(Binaries of the package requested to be added to main are
the library files, not the executable.)

- CVE History:
	- CVE-2017-13135
	- CVE-2017-13666
	- CVE-2017-8906
- Build-Depends?
	- debhelper-compat (= 13), cmake, git, libnuma-dev , nasm (>= 2.13)
	- (indep) python3-sphinx
- pre/post inst/rm scripts?
	- None
- init scripts?
	- None
- systemd units?
	- None
- dbus services?
	- None
- setuid binaries?
	- None
- binaries in PATH?
	- /usr/bin/x265 -> not considered for main
- sudo fragments?
	- None
- polkit files?
	- None
- udev rules?
	- None
- unit tests / autopkgtests?
	- It has simple autopkgtest
	- Use ffmpeg to produce a 10s test image, and use x265 to encode to H.265/HEVC
	- It has unit tests -> PASS 100%
- cron jobs?
	- None
- Build logs:
	- One lintian warning in documentation:
	- W: libx265-doc: national-encoding usr/share/doc/libx265-dev/html/_sources/cli.rst.txt

- Processes spawned?
	- No processes spawned, threading used.
	- Threads are created from the video processing tasks, "one per encoder" stated in the documentation.
- Memory management?
	- The library has several memory-leaking issues.
	- As this is an API library, most of the memory management would fall under the developer side.
- File IO?
	- Paths are not sanitized. The developer is responsible for sanitizing the input.
- Logging?
	- All logs have format/don't use variables (are safe against format string vuln).
- Environment variable usage?
	- It doesn't use environment variables.
- Use of privileged functions?
	- No
- Use of cryptography / random number sources etc?
	- No cryptography
- Use of temp files?
	- No
- Use of networking?
	- No
- Use of WebKit?
	- No
- Use of PolicyKit?
	- No

- Any significant cppcheck results?
	- None
- Any significant Coverity results?
	- 278 issues found. Some falling under:
	- UAF / Double Free
	- Integer overflow
	- Resource leak
- Any significant shellcheck results?
	- Nothing important, some small issues with build scripts.
- Any significant bandit results?
	- None

Source code analysis:

* 215640 lines of ASM code (imported from x264, in universe).

* Heap buffer overflow leading to heap leak address found on x265 binary.
	1 week since the vulnerability was reported, no response yet.

* Issues found when using the API as it's supposed to:
	- Missing cast to long in CHECKED_MALLOC and CHECKED_MALLOC_ZERO
	- printf issues: possible long as %d
	- Several integer overflows, u32 mult then assigned to a u64
	- strdup(value) never freed -> memory leak
	- x265::x265_malloc -> memory leak when creating encoder
	- x265::x265_copy_params -> memory leak (pools argument)
	- x265_param_parse -> memory leak (pools argument)
	- parseScalingList never closes file descriptor if any error occurs.

* API is not safe for untrusted input. It does not validate the input
	or performs bound checks. It depends on the developer building
	the frontend to ensure the data provided is valid. Issues:
	- Specifying a higher size than the size of the provided
	image data in encoder -> Heap buffer overflow
	- SEGV due to accessing an invalid address in x265::determineLevel
	when params are not properly set.

Community activity:
	- The link for issues is broken (although easy to find as it's BitBucket).
	- Issues are filled up with spam.
	- No special security contact method was provided.
	- Several security issues reported, up to 2017, unresolved or ignored.
	Around 250 real open issues, examples:
	- https://bitbucket.org/multicoreware/x265_git/issues/467/threadsanitizer-reported-several-data
	- https://bitbucket.org/multicoreware/x265_git/issues/364/integer-overflow-and-affect-top-level
	- https://bitbucket.org/multicoreware/x265_git/issues/469/ffmpeg-libx265-crashes-with-bad-keyframe
	- https://bitbucket.org/multicoreware/x265_git/issues/482/leak-memory

Due to the fact that the safety of this library depends on a very robust frontend
(i.e. no untrusted input or heavy input checks) and the several open and found issues,
security team NACK for promoting x265 to main.