[MIR] x265 (dependency of libheif)

updated security impact since encoders might also be exploited, e.g. https://github.com/duc-nt/CVE-2022-44268-ImageMagick-Arbitrary-File-Read-PoC

Review for Package: x265

[Summary]
MIR team ACK under the constraint (quite a few) to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.
Please ping back for a re-evaluation once they are resolved.

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: libx265-doc, libx265-dev, libx265-199

Specific binary packages built, but NOT to be promoted to main: x265
This isn't forbidden, but the use by libheif will not pull it in.
If wanted this would need to be seeded as supported.

Required TODOs:
#1 - as i said on 2004449 libde265 - it would be great if we could pick just
     one. Please have an investigation with upstream before supporting both.
     From far away it seems x265 is preferred for encoding (as it is under
     development in de265 still) but vice versa libde265 for decoding (no
     reason given/found)
#2 - There is code for that in source/test/regression-tests.txt and it would
     be great to run this at build time and autopkgtest time.
#3 - engage with the community on the example of bug 1915012. This isn't so much
     about this particular bug but about ensuring if mail or bug tracking or all
     that which you'd expect works well.
     Please check that way if this can be a healthy two way relationship or if
     we'd sign up for something with a dying community (more examples why that
     could be below)

Recommended TODOs:
#4 - it is great that this has tests at all (based on ffmpeg + x265) but please
     ensure that here or in libheif (or both) there is a test for libheif
     using x265 as autopkgtest
#5 - if you are in a bug fix frenzy maybe try to understand and fix
     https://bugs.launchpad.net/ubuntu/+source/x265/+bug/1909949

[Duplication]
As mentioned in 2004449 libde265, in theory both libraries provide the same.
There seems to be a preference to use one for decoding and one for encoding.
But it feels one should give a try to settle on one, it seems libde has more
frequent fixed and releases.

While I'd wish we could pick just one, it seems that isn't working well.
I'll add a todo to at least try this and maybe disuss it upstream.
=> There is no other package in main providing the same functionality (kind of).

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
  - there is libx265-doc but is only needs libjs-sphinxdoc which is in main
  - there also is libx265-dev but it has no external dependencies
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- history of CVEs does not look concerning (a few in the past as expected,
  but no open ones nor too many)
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not process arbitrary web content
- ...

Regarding x265 vs libde265, note that x265 is an encoder only. It will never support decoding.

[Duplication]
I have asked upstream whether libde265 encoder can be used, and apparently it is abandoned. While technically there is an ability to encode, but speed and quality is not competitive [1].

[1] https://github.com/strukturag/libheif/issues/797#issuecomment-1476844774

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
 ...

This got NACK'ed by Security. So, I'm closing it WONTFIX.

See https://bugs.launchpad.net/ubuntu/+source/libheif/+bug/1827442/comments/50 (and previous comments on that bug) for an alternative plan.