[MIR] speexdsp

[Sebastien Bacher]

[Availability]
The package speexdsp is already in Ubuntu universe.
The package speexdsp build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64 arm64 armhf ppc64el riscv64 s390x
Link to package https://launchpad.net/ubuntu/+source/speexdsp

The corresponding case in main as part of speex until Lunar and then split out.

[Rationale]
- The package speexdsp is required in Ubuntu main as a depends of roc-toolkit which we want to MIR as a new pipewire (optional) requirement
- The corresponding plugin will not be used by default in Ubuntu but we still want it available. We could split it to a new binary that would go to universe but then it would need to be manually installed and force us to carry a packaging delta over Debian.
- There is no other/better way to solve this that is already in main or
  should go universe->main instead of this.

- The package speexdsp is required in Ubuntu main no later than Feb 29 due to the Noble Feature Freeze

[Security]
- No CVEs/security issues in this software in the past (there are 3 existing speex CVE for pre-source-split versions but none of those concern the code which was split into speexdsp)

- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024).
- Package does not expose any external endpoints
- Packages does not contain extensions to security-sensitive software

[Quality assurance - function/usage]
- The package works well right after install

- The package is maintained well in Debian/Ubuntu/Upstream and has
  no open bug downstream and a few minor ones upstream
  - Ubuntu https://bugs.launchpad.net/ubuntu/+source/speexdsp/+bug
  - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=speexdsp
  - Upstream's bug tracker, https://gitlab.xiph.org/xiph/speexdsp/-/issues
- The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]
- The package does not run a test at build time because upstream doesn't provide any. Also it's an audio codec implementation so not something easily testable in CI.

- The package has a simple buildtest autopkgtest for the library but can't really be tested in CI for the same reason as build tests.

- Seexdsp is pulled in as a depends of roc-toolkit (MIR bug #2047150) and the codec will be tested also by the roc-toolkit and through pipewire integration (a section has been added to https://wiki.ubuntu.com/DesktopTeam/TestPlans/Pipewire)

[Quality assurance - packaging]
- debian/watch is present and works

- debian/control defines a correct Maintainer

- This package has no important lintian warnings

# lintian --pedantic speexdsp_1.2.1-1_amd64.changes
P: speexdsp source: silent-on-rules-requiring-root [debian/control]
P: speexdsp source: trailing-whitespace [debian/changelog:11]

- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies

- The package will be installed by default, but does not ask debconf questions

- Packaging and build is easy, link to debian/rules https://salsa.debian.org/multimedia-team/speexdsp/-/blob/master/debian/rules

[UI standards]
- Application is not end-user facing (does not need translation)

[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]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The future owning team is already subscribed to the package

- This does not use static builds
- This does not use vendored code
- This package is not rust based

- The package has been built in the archive more recently than the last test rebuild

[Background information]
The Package description explains the package well
Upstream Name is speexdsp
Link to upstream project https://gitlab.xiph.org/xiph/speexdsp

[Didier Roche-Tolomelli (didrocks)]

I think you are aware that as there is no test and it’s not testable due to the fact that it’s audio file codec (even if one day, a framework for testing this seems to be something that is desirable), we need then some manual testing with every upload as a stop gap solution. Mind providing this? Then, I will review the MIR.

[Didier Roche-Tolomelli (didrocks)]

Feel free to reassign once ok.

[Sebastien Bacher (seb128)]

@Didier, I've clarified the testing story, the codec will be (lightly) tested through the roc-toolkit tests (which is the component consuming the library). I've also added a section to https://wiki.ubuntu.com/DesktopTeam/TestPlans/Pipewire for manual testing coverage.

Also note that the speexdsp code had been in main as part of speex until jammy as mentioned in the description which probably means it can do with a lighter review

[Didier Roche-Tolomelli (didrocks)]

Review for Source Package: speexdsp

[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
List of specific binary packages to be promoted to main: libspeexdsp1, libspeexdsp-dev

Notes:
Required TODOs:
- There is no symbol tracking in place. It seems the library is build from C and it should be easy to get that added.
Recommended TODOs:
- The package should get a team bug subscriber before being promoted

[Rationale, Duplication and Ownership]
There is no other package in main providing the same functionality as it’s a split of another package.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- speexdsp 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.

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries

OK:
- not a go package, no extra constraints to consider in that regard
- Does not include vendored code

[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 expose any external endpoint (port/socket/... or similar)
- 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, ...)
- this makes appropriate (for its exposure) use of established risk
  mitigation features (dropping permissions, using temporary environments,
  restricted users/groups, seccomp, systemd isolation features,
  apparmor, ...)

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

[Common blockers]
OK:
- does not FTBFS currently
- no new python2 dependency

Problems:
- does have a trivial test suite than runs as autopkgtest and no upstream tests. Manual test plan requested as it’s processing audio file and the desktop team doesn’t have the capacity to write a decoder tests for that project. An update to the description has been done to include the manual test plan link and will be executed at each upload of the package.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- debian/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is slow, but the codec doesn’t evolve
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
- no massive Lintian warnings
- debian/rules ...

[Mark Esler (eslerm)]

Security will begin our review after we complete the roc-toolkit MIR (LP#2047150).

[George-Andrei Iosif (iosifache)]

I reviewed `speexdsp` `1.2.1-1` as checked into Noble. This shouldn't be
considered a full audit, but rather a quick gauge of maintainability that
involves static and dynamic analysis techniques.

Speex is an open-source and free audio compression codec specialised in
reproducing human speech (at low bitrates, ~2.1–32 kbit/s/channel). The
format is contained by other formats such as Ogg and Flash Video.

The format was replaced by its parent organisation, Xiph, with the Opus format.
Despite its obsoletion, the format is still supported by open-source software
such as [OpenWrt](https://github.com/openwrt/packages/issues/3747).

SpeexDSP is a library that includes the preprocessor, the acoustic echo
canceller, the jitter buffer, and the resample. It should be noted that
`speexdsp`'s code was part of main until Ubuntu 22.04. Before this release, the
codebase wasn't represented by a separate package but as part of the `speex`
package.

As SpeexDSP is a no-dependency library, it can be linked by programs with
`-lspeexdsp -lm`. Likewise, the simple input is the Speex-encoded data provided
by the program linking SpeexDSP. As the library is written in C but lacks OS
interaction, the codebase is prone to memory corruption issues that may
ultimately lead to code execution in the context of the parent process.

- CVE History
  - There is no CVE issued for SpeexDSP.
  - The Speex library, which is a sibling codebase as `speexdsp` was derived
from it, has two other CVEs in the past:
    - CVE-2020-23904: Bogus stack buffer overflow that couldn't be validated by
the maintainers.
    - CVE-2020-23903: Division by zero in `speexenc`, an example program
  - The Speex sibling codebase was also integrated into OSS-Fuzz.
    - The integration definition files are placed in the
[Speex](https://gitlab.xiph.org/xiph/speex/-/blob/master/contrib/oss-fuzz/speexd
ec_fuzzer.cc) and
[OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/speex)
repositories.
    - [There are 13
bugs](https://bugs.chromium.org/p/oss-fuzz/issues/list?q=speex&can=1) between
2019 and 2021 that were maturely tackled by the maintainers.
- Build-Depends
  - It depends only on `libm` and `libc`.
- pre/post inst/rm scripts
  - N/A
- init scripts
  - N/A
- systemd units
  - N/A
- dbus services
  - N/A
- setuid binaries
  - N/A
- binaries in PATH
  - N/A
- sudo fragments
  - N/A
- polkit files
  - N/A
- udev rules
  - N/A
- unit tests / autopkgtests
  - There is no unit test for the whole codebase.
  - The encoding and decoding of the Speex code are tested in the
previously-mentioned sibling codebase and OSS-Fuzz.
- cron jobs
  - N/A
- Build logs
  - N/A

- Processes spawned
  - N/A
- Memory management
  - The allocations take place for the members of the "states". These are
internal structures, with multiple fields, that contain the current state of a
given operation executed by the library.
  - The library defines wrappers over the standard memory management functions
in its `libspeexdsp/os_support.h` file. These wrapper functions are called in
all files where memory management is needed. The functions are properly called:
if the library allocates a lot of ...

[Sebastien Bacher (seb128)]

Thanks. I've added the .symbols/made the build stop on changes, forwarded that delta to Debian and subscribed desktop-packages

Promoting now