[MIR] libyuv (transitive dependency of libheif)

[Vladimir Petko]

[Availability]

The package libyuv is already in Ubuntu universe.
The package libyuv build for the architectures it is designed to work on.
It currently builds and works for architectures:
amd64 arm64 armhf i386 ppc64el riscv64 s390x

Link to package https://launchpad.net/ubuntu/+source/libyuv

[Rationale]

- The package libyuv will not generally be useful for a large part of
  our user base, but is important/helpful still because it provides color
  format conversion and scaling which is important for video processing
- The package libyuv is a transitive dependency of package libheif that
  we intend to support
- It would be great and useful to community/processes to have the
  package libyuv in Ubuntu main, but there is no definitive deadline.

[Security]

- No CVEs/security issues in this software in the past
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does contain extensions to security-sensitive software:
  the package colorspace conversion library which processes untrusted input

[Quality assurance - function/usage]

- The package works well right after install

[Quality assurance - maintenance]

- The package is maintained well in Debian/Ubuntu and has not too many
  and long term critical bugs open
  - Ubuntu https://bugs.launchpad.net/ubuntu/+source/libyuv/+bug
  - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libyuv
- The package has no important open bugs.
  Note: patches need to be refreshed.
- The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]

- The package runs a test suite on build time, if it fails
  it makes the build fail, link to build log:
  https://launchpadlibrarian.net/625029537/buildlog_ubuntu-kinetic-amd64.libyuv_0.0~git20220809.9b17af9-1ubuntu2_BUILDING.txt.gz
  Note: unit tests are disabled for architectures:
  arm64 armel s390x powerpc ppc64 sparc64
- The package does not run an autopkgtest because it is not implemented

[Quality assurance - packaging]

- debian/watch is present and works
- debian/control does not define a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Please link to a recent build log of the package
  https://launchpadlibrarian.net/625029537/buildlog_ubuntu-kinetic-amd64.libyuv_0.0~git20220809.9b17af9-1ubuntu2_BUILDING.txt.gz
- Please attach the full output you have got from
  `lintian --pedantic` as an extra post to this bug.
- Lintian overrides are not present
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default
- Packaging and build is easy, link to d/rules
  https://git.launchpad.net/ubuntu/+source/libyuv/tree/debian/rules

[UI standards]

- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because
  it does not provide any GUI

[Dependencies]

- No further depends or recommends dependencies that are not yet in main

[Standards compliance]

- This package correctly follows FHS and Debian Policy

[Maintenance/Owner]

- Owning Team will be Foundations Team
- Team is not yet, but will subscribe to the package before promotion
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package successfully built during the most recent test rebuild
  Note: Build on lunar takes extremely long time compiling
  unit_test/convert_test.cc.
  https://launchpadlibrarian.net/640219928/buildlog_ubuntu-lunar-amd64.libyuv_0.0~git20220809.9b17af9-1ubuntu2_BUILDING.txt.gz
  Is it a known GCC issue?
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    0x0000000000917faf in bitmap_set_bit(bitmap_head*, int) ()
    (gdb) where
    #0 0x0000000000917faf in bitmap_set_bit(bitmap_head*, int) ()
    #1 0x0000000000f62ed2 in ?? ()
    #2 0x0000000000f636d1 in compute_may_aliases() ()
    #3 0x0000000000cc0fad in ?? ()
    #4 0x0000000000cc156f in ?? ()
    #5 0x0000000000cc45f7 in execute_one_pass(opt_pass*) ()
    #6 0x0000000000cc4af0 in ?? ()
    #7 0x0000000000cc4b02 in ?? ()
    #8 0x0000000000cc4b2d in execute_pass_list(function*, opt_pass*) ()
    #9 0x0000000000984e68 in cgraph_node::expand() ()
    #10 0x0000000000986397 in ?? ()
    #11 0x00000000009888ac in symbol_table::finalize_compilation_unit() ()
    #12 0x0000000000d92060 in ?? ()
    #13 0x00000000006a48fe in toplev::main(int, char**) ()
    #14 0x00000000006a5fef in main ()

[Background information]

The Package description explains the package well
Upstream Name is libyuv
Link to upstream project https://chromium.googlesource.com/libyuv/libyuv

[Ioanna Alifieraki (joalif)]

Review for Package: libyuv

[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.
This does need a security review, so I'll assign ubuntu-security once required TODOs
are resolved.
List of specific binary packages to be promoted to main: libyuv0, libyuv-dev, libyuv-utils

Notes:
TODO: - add todos, issues or special cases to discuss
Required TODOs:
1. Please add autopkgtests, the test running at build time can be used for this.
2. Ubuntu current release is behind debian by 8 versions, please sync.
   In newer versions debian has disabled lto because of some tests failing.
Recommended TODOs:
3. Not sure this is a problem wrt MIR but I'll mention it to take a look at just in case.
   I was not able to build the package because it would complain:
   "dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address".
   Looking at d/control
   "Maintainer: Debian Multimedia Maintainers <email address hidden>".
   This does not seem to be a problem when building on launchpad.

- The package should get a team bug subscriber before being promoted

[Duplication]
This package is required in main as a dependency of libheif package.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - libuyv checked with `check-mir`
  - all dependencies can be found in `seeded-in-ubuntu` (already in main)
  - none of the (potentially auto-generated) dependencies (Depends
    and Recommends) that are present after build are not in main
- no -dev/-debug/-doc packages that need exclusion
- 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
- Does not include vendored code

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- 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
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems:
- does parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- This does not need special HW for build or test
- no new python2 dependency

Problems:
- does not have a non-trivial test suite that runs as autopkgtest

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under
  control
- symbols tracking is in...

[Lukas Märdian (slyon)]

UPDATE:

I see the latest version 0.0~git202401110.af6ac82-1 is a sync from Debian and also provides some non-superficial autopkgtests. So the required MIR TODOs seems to be solved. I subscribed ~foundations-bugs and moving it into the security queue.

[Seth Arnold (seth-arnold)]

Hello, the MIR process says any MIRs assigned to the security team after
the Beta Freeze deadline need to be discussed with the Director of
Security Engineering:

    For a MIR to be considered for a release, it must be assigned to the
    Security team (by the MIR team) before Beta Freeze. This does not
    guarantee that a security review can be completed by Final Release.
    Ask the director of Security for exceptions.

https://github.com/canonical/ubuntu-mir?tab=readme-ov-file#security-reviews

Please find a few minutes on Alex Burrage's calendar and schedule
a meeting.

Thanks

[Lukas Märdian (slyon)]

ravi-sharma> I sent a message to Alex to request an exception.

[Ravi Kant Sharma (ravi-sharma)]

Alex has granted the exception with a note advising against last minute security reviews in the future.

[Mark Esler (eslerm)]

When is Security review absolutely needed by? Is April 17th, the day before Final Freeze okay? Would that give Foundation's enough time to promote to main?

There may not be enough time for Security to complete a review by Final Freeze, but we are looking for someone to take this asap.

[Mark Esler (eslerm)]

I reviewed libyuv 0.0~git202401110.af6ac82-1 as checked into noble. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

libyuv is an open source project that includes YUV scaling and conversion functionality.

- CVE History:
  - none
  - open bug reports are not a security concern
    - https://bugs.chromium.org/p/libyuv/issues/list
- Build-Depends?
  - googletest build depend
- pre/post inst/rm scripts?
  - none
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - none
- binaries in PATH?
  - from libyuv-utils
    - ./usr/bin/yuvconstants
    - ./usr/bin/yuvconvert
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - from d/rules, it appears all tests on armel s390x powerpc ppc64 and sparc64 are disabled
  - on amd64, 40 disabled tests
  - 256 counts of -Wstringop-overflow in build logs due to tests
  - more bugs in test possible, see coverity section
  - rather thorough testing otherwise
- cron jobs?
  - none
- Build logs:
  - missing man pages for binaries
  - 256 counts of -Wstringop-overflow due to tests

- Processes spawned?
  - only in python, and in a script for maintaining upstream deps
    - not relevant
- Memory management?
  - tests cause string overflows with memtest
    - just a bug, not a security concern
  - see coverity section
  - moderate memcpy use outside of tests
    - looks okay
- File IO?
  - c++ fopen use appears safe
  - ignoring python upstream maintenance helper scripts
- Logging?
  - no logging outside of python
  - Python uses logging.debug and logging.error
- Environment variable usage?
  - only used for tests
- Use of privileged functions?
  - none
- Use of cryptography / random number sources etc?
  - none
- Use of temp files?
  - none
- Use of networking?
  - none
- Use of PolicyKit?
  - none

- Any significant cppcheck results?
  - not a concern
- Any significant Coverity results?
  - non-security bug reported
    - https://bugs.chromium.org/p/libyuv/issues/detail?id=979
  - many more non-relevant issues in tests
    - ignoring
    - upstream should improve unit tests.
  - ./tools_libyuv/ seems dangerous, but appears to only be for upstream maintenance
    - okay
  - unchecked return in ./util/yuconvert.cc:243
  - report of uninitialized scalar variabile in ./util/yuconvert.cc seems difficult to trigger
  - MJpegDecoder::MJpegDecoder() does not initialize buf_vec_.pos
    - this is set early in MJpegDecoder::LoadFrame(), so probably *fine*
- Any significant shellcheck results?
  - none
- Any significant bandit results?
  - none
  - only in irrelevant source code maintenance scripts

This was an expedited and less thorough review.

Security team ACK for promoting foot to main.

[Lukas Märdian (slyon)]

This is now ready and can be promoted with the rest of the libgd2 -> libheif -> PLUGINS -> CODECS chain

[Christian Ehrhardt  (paelzer)]

Slight change here - this isn't needed for libaom3.

Due to the good use of non-embedded libs we now have correct dependency tracking.
That shows that only aom-tools would needed it, which isn't pulled in from libheif.

We could promote it, but if you want that you'd need to seed aom-tools (if it is serving a good purpose) in one of the -supported seeds I guess.

A bit more detail in https://bugs.launchpad.net/ubuntu/+source/libheif/+bug/1827442/comments/55

[Lukas Märdian (slyon)]

Thanks for the investigation of the new dependency tracking!
I missed that previously. Sorry for all the extra work involved for getting this landed in time!

I'll unsubscribe ~foundations-bugs and move it to "In Progress", as the MIR still passed. So it has the correct state, should it be needed by any team in the future.