Comment 5 for bug 2004449

I reviewed libde265 1.0.12-1build1 as checked into mantic. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

libde265 is an open-source implementation of the h.265 video codec. It provides
both an encoding and decoding API but the main objective of the library is to
provide h.265 decoding, as the encoding part is not actively developed [1]

This package was requested due to it being a dependency of libheif.
Note that libheif is developed by the same developer as libde265.

- CVE History
  - 48 CVEs since 2020.
  - The developer started to commit seriously to patching CVEs recently
    * Several security-only releases in the past months.
    * One of them patched 30 CVEs.
    * Reference to specific commits patching the CVE.
  - Issues were not addressed on time but recent upstream activity shows
    that the developer is now actively answering and fixing them.
- Build-Depends
  - All libraries are related to image processing, nothing out of normal.
- pre/post inst/rm scripts
  - None
- init scripts
  - None
- systemd units
  - None
- dbus services
  - None
- setuid binaries
  - None
- binaries in PATH
  - from the ".*examples" binary:
    - libde265-sherlock265: QT video player.
    - libde265-dec265: simple player for h.265 bitstreams.
- sudo fragments
  - None
- polkit files
  - None
- udev rules
  - None
- unit tests / autopkgtests
  - No unit tests available in the software.
  - No autopkgtests.
  - CI/CD in GitHub uses example input files to test (x86 and arm) as well as Valgrind + Coverity analysis.
- cron jobs
  - None
- Build logs
  - Some macro warnings.
  - Some libtool reminder warnings.
  - Some warnings related to exceeding maximum object size, depending on the input file.
- Processes spawned
  - No process spawned in the library, only on the tools and the examples.
- Memory management
  - The code performs checks to ensure malloc doesn't fail.
  - The code doesn't check the boundaries when calling memcpy (on internal functions only).
    Hard to trace if everything is checked before but many of the CVEs are because of assuming the right inputs.
  - Sprintfs are handled safely by using limits on the size.
- File IO
  - Library reads H.265/HEVC files to decode/encode them.
  - The API functions don't sanitize paths but it's a library so it should be checked by the frontend application.
  - No umask usage
- Logging
  - Done safely through local specific functions.
  - No possibility of format string.
- Environment variable usage
  - None
- Use of privileged functions
  - None
- Use of cryptography / random number sources etc
  - None
- Use of temp files
  - Only on the tools, not on the library.
- Use of networking
  - None
- Use of WebKit
  - None
- Use of PolicyKit
  - None

- Any significant cppcheck results
  - Mainly non-serious issues related to the encoder.
  - One issue related to memory management, no check in case of an error that will result in BOF.
- Any significant Coverity results
  - Nothing significant.
- Any significant shellcheck results
  - None
- Any significant bandit results
  - No Python code.
- Any significant govulncheck results
  - No Go code.
- Any significant Semgrep results
  - Nothing significant

The code seems to be a work in progress, with 195 TODO comments in master as of today, and lots of commented pieces of code. There is no security policy in place [2].

The developer uploads this software as deb packages in LP [3]. There is an extra package
called libde265-teststreams that contains examples and fuzzing cases that are also run during CI/CD. They could be used as autopkgtests. More examples can also be found in [4]

Releases are erratic, in the past 6 months the developer has published several security updates and other fixes but there was a 2-year gap from 2022 to 2020.

During the analysis, 2 vulnerabilities were discovered and reported [5][6]. The developer
quickly acknowledge and push fixes to the repository.

The encoding feature is not actively maintained and therefore this package
shouldn't be used for that purpose.

Security team ACK for promoting libde265 to main.

[1] https://github.com/strukturag/libheif/issues/797#event-8800456603
[2] https://github.com/strukturag/libde265/issues/420
[3] https://launchpad.net/~strukturag/+archive/ubuntu/libde265
[4] https://github.com/strukturag/libde265-data
[5] https://github.com/strukturag/libde265/issues/418
[6] https://github.com/strukturag/libde265/issues/419