Review for Source Package: gstreamer-plugins-bad1.0 (a subset of which will form the proposed gstreamer-plugins-extra1.0 binary)
[Summary] The essence of the review result from the MIR POV is that the components of gstreamer-plugins-bad1.0 that are requested for review as part of a new binary, gstreamer-plugins-extra1.0, are generally compliant with the MIR process aside from the required TODOs. A security review is still recommended as this package parses potentially untrusted media data formats. MIR team ACK under the constraint to resolve the below listed required TODOs. This does need a security review, so I'll assign ubuntu-security List of specific binary packages to be promoted to main: - gstreamer1.0-plugins-extra - libgstreamer-plugins-extra1.0-0 - libgstreamer-plugins-extra1.0-dev - gir1.2-gst-plugins-extra-1.0 Specific binary packages built, but NOT to be promoted to main: - gir1.2-gst-plugins-bad-1.0 - gstreamer1.0-opencv - gstreamer1.0-plugins-bad - gstreamer1.0-plugins-bad-apps - libgstreamer-opencv1.0-0 - libgstreamer-plugins-bad1.0-0 - libgstreamer-plugins-bad1.0-dev Notes: Required TODOs: - Enable symbols tracking for public libraries - Ensure package is not on the LTO-disabled list - gst-plugins-bad1.0 is on the list for ppc64el and s390x (https://git.launchpad.net/ubuntu/+source/lto-disabled-list/tree/lto-disabled-list) [Rationale, Duplication and Ownership] There is no other package in main providing the same functionality. A team is committed to own long term maintenance of this package (desktop-packages). The rationale given in the report seems valid and useful for Ubuntu. [Dependencies] OK: - no other runtime Dependencies to MIR due to this - all runtime dependencies for libgstreamer-plugins-extra1.0-0_1.26.5-1ubuntu3_amd64.deb and gstreamer1.0-plugins-extra_1.26.5-1ubuntu3_amd64.deb were checked and are confirmed to be in main. - no other build-time Dependencies with active code in the final binaries to MIR due to this - 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 OK: - not a go package, no extra constraints to consider in that regard - No vendoring used, all Built-Using are in main - 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 parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source. A security review is recommended to ensure this functionality follows best practices. - 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: - This package does parse media data formats and a security review is recommended to ensure best security practices are being followed. [Common blockers] OK: - does not FTBFS currently (PPA build https://launchpad.net/~charles05/+archive/ubuntu/gstreamer/+build/31313921 looks good) - does have a test suite that runs at build time - test suite fails will fail the build upon error. - This does seem to need special HW for build or test so it can't be automatic at build or autopkgtest time. But as outlined by the requester in [Quality assurance - testing] there: - is hardware and a test plan or code that tests various aspects of GStreamer such as different video/audio codecs and integrations. This is outlined in the link provided by the MIR submitter: https://wiki.ubuntu.com/DesktopTeam/TestPlans/GStreamer - no new python2 dependency Problems: None [Packaging red flags] OK: - Ubuntu does carry a delta, but it is reasonable and maintenance under control - For c++ libraries - symbols tracking isn't in place but the owning team tried to set it up and came back with a reasonable rationale of why it isn't practical to do for the package. If symbols tracking isn't used then it's recommended to investigate using an alternative like abigail or abi-compliance-check in CI or bumping SOVER with every package update. - debian/watch is present and looks ok - Upstream update history is good - updates at least weekly - Debian/Ubuntu update history is good - at least monthly - the current release is packaged - promoting this does not seem to cause issues for MOTUs that so far maintained the package - no massive Lintian warnings - debian/rules is quite complex, but to be expected given the complex nature of this source package - the package is on the LTO-disabled-list the architectures ppc64el and s390x Problems: - It appears that libgstreamer-plugins-extra1.0-0 is a public library but does not have symbols tracking in place. Symbols tracking or an alternative such as abigail or abi-compliance-check should be used. [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (as far as we can check it) - no incautious use of malloc/sprintf (the language has no direct MM) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside tests) - no use of user 'nobody' outside of tests - no use of setuid / setgid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit or libseed - not part of the UI for extra checks - no translation present, but none needed for this case Problems: None ** Changed in: gst-plugins-bad1.0 (Ubuntu) Assignee: Myles Penner (mylesjp) => (unassigned) ** Changed in: gst-plugins-bad1.0 (Ubuntu) Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-bad1.0 in Ubuntu. https://bugs.launchpad.net/bugs/2121050 Title: [MIR] gstreamer-plugins-extra1.0 Status in gst-plugins-bad1.0 package in Ubuntu: New Bug description: [Introduction] The current structure of gst-plugins-bad1.0 presents several challenges for its wholesale inclusion in main, particularly concerning its dependencies and the ongoing difficulties upstream in categorising GStreamer elements. This proposal seeks to address these issues by creating a new binary package, gstreamer1.0-plugins-extra, to house a targeted subset of components currently residing in the gst-plugins-bad1.0 source package. Upstream GStreamer development has consistently struggled with the classification and reorganisation of its elements. Attempts to split elements, such as those detailed in [1], or reorganise release tarballs [2], have frequently stalled. Similarly, proposals to move smaller, stable components from -bad to -good, even when championed by experienced upstream maintainers, have met with similar delays [3, 4]. While upstream wants to promote plugins from -bad to -good, it is not a high priority for them, and promises to do so have frequently slipped from release to release. Despite these upstream challenges, a significant driver for this proposal is the presence of hard dependencies on gst-plugins-bad1.0 components from existing main packages (like GTK4, GNOME apps). To date, workarounds for these dependencies have involved unsustainable practices, including: - Vendoring an obsolete playback library within GTK4. - Patching gstreamer1.0-plugins-good (a main package) with elements that originate from gstreamer1.0-plugins-bad (a universe package) so that GNOME apps that depend on the bad elements can find them in main. These workarounds not only bypass essential security reviews but also introduce a considerable maintenance burden due to the need to perpetually update these patches. This often results in users unknowingly relying on outdated and potentially vulnerable versions of these patched components. Further details and discussion regarding this proposed split can be found in the Launchpad bug report [5]. Therefore, to resolve these issues and establish a more future-proof solution, this MIR proposes creating a new binary package, gstreamer1.0-plugins-extra, from the existing gst-plugins-bad1.0 source package. This naming convention aligns with prior upstream discussions and agreements regarding element nomenclature [2]. This split will allow essential GNOME-related dependencies to reside in a main eligible package, facilitating proper security review and reducing the maintenance overhead currently imposed by the workarounds. The work is also a prerequisite to shipping Showtime (https://bugs.launchpad.net/ubuntu/+source/showtime/+bug/2115912) as a main package, since that package has -bad dependencies. [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6130 [2] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3320 [3] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1758 [4] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2386 [5] https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/2027594 [Availability] The package gst-plugins-bad1.0 is already in Ubuntu universe. The package gst-plugins-bad1.0 build for the architectures it is designed to work on. It currently builds and works for architectures: amd64, arm64, armhf, i386, riscv64 s390x Link to package https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0 [Rationale] RULE: There must be a certain level of demand for the package A subset of the package gst-plugins-bad1.0 is required in Ubuntu main for the reasons outlined in the introduction. The subset of gst-plugins-bad1.0 will generally be useful for a large part of our user base. There is no other/better way to solve this that is already in main or should go universe->main instead of this if we wish to be in line with GNOME. This is the first time package will be in main The binary package gst-plugins-extra1.0 needs to be in main to achieve basic media functionality in the existing desktop package set. All other binary packages built by gst-plugins-bad1.0 should remain in universe. The package gst-plugins-extra1.0 is required in Ubuntu main no later than 26.04 due to the desktop moving from Totem to Showtime, and to ensure the other dependents of gst-plugins-extra1.0 can stop vendoring / patching. [Security] In terms of new code to review, the shared objects proposed for inclusion are, gstreamer1.0-plugins-extra_1.26.4-1ubuntu2_amd64.deb -rw-r--r-- root/root 92888 2025-08-04 11:44 ./usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so -rw-r--r-- root/root 576024 2025-08-04 11:44 ./usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstva.so libgstreamer-plugins-extra1.0-0_1.26.5-1ubuntu2_amd64.deb -rw-r--r-- root/root 31048 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstbasecamerabinsrc-1.0.so.0.2605.0 -rw-r--r-- root/root 859520 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstcodecparsers-1.0.so.0.2605.0 -rw-r--r-- root/root 231752 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstcodecs-1.0.so.0.2605.0 -rw-r--r-- root/root 39080 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstphotography-1.0.so.0.2605.0 -rw-r--r-- root/root 145736 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstplay-1.0.so.0.2605.0 -rw-r--r-- root/root 90064 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstva-1.0.so.0.2605.0 RULE: The security history and the current state of security issues in the RULE: package must allow us to support the package for at least 9 months (120 RULE: for LTS+ESM support) without exposing its users to an inappropriate level RULE: of security risks. This requires checking of several things: RULE: - Search in the National Vulnerability Database using the PKG as keyword RULE: https://cve.mitre.org/cve/search_cve_list.html I did not see any CVEs for the plugins / libraries we're proposing to be moved over. RULE: - check OSS security mailing list (feed into search engine RULE: 'site:www.openwall.com/lists/oss-security <pkgname>') Nothing found here either. RULE: - Ubuntu CVE Tracker RULE: https://ubuntu.com/security/cve?package=<source-package-name> - "The security API is down. An error occurred while fetching security data" RULE: - Debian Security Tracker RULE: https://security-tracker.debian.org/tracker/source-package/<source-package-name> Had 8 security issues in the past. All were in the codecparsing component. - https://security-tracker.debian.org/tracker/TEMP-0000000-C6AAE1 - https://security-tracker.debian.org/tracker/CVE-2025-6663 - https://security-tracker.debian.org/tracker/CVE-2025-3887 - https://security-tracker.debian.org/tracker/CVE-2023-50186 - https://security-tracker.debian.org/tracker/CVE-2023-44429 - https://security-tracker.debian.org/tracker/CVE-2023-40475 - https://security-tracker.debian.org/tracker/CVE-2021-3185 - https://security-tracker.debian.org/tracker/CVE-2016-9809 (since refactored into codecparsers) All were handled properly, but this is a significant risk. Codec parsing is notorious for security issues across platforms, and applications using this component absolutely should be sandboxed. no `suid` or `sgid` binaries no executables in `/sbin` and `/usr/sbin` Package does not install services, timers or recurring jobs It would be the applications using these media elements to ensure appropriate isolation/risk-mitigation measures are in place. Package does not open privileged ports (ports < 1024). Package does not expose any external endpoints Package does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...) [Quality assurance - function/usage] The package works well right after install [Quality assurance - maintenance] The package is maintained well in Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs - Ubuntu https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gst-plugins-bad1.0 - Upstream's bug tracker https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/ Due to the ubiquitous nature of GStreamer within the FOSS stack, there are many reported and open bugs. However, there's also an active maintainer-ship, and critical bugs are addressed quickly. 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/808473923/buildlog_ubuntu-questing-amd64.gst-plugins-bad1.0_1.26.4-1ubuntu1_BUILDING.txt.gz The package does not run an autopkgtest because no one has had time to do so. There's also a large bug surface specific to physical hardware, which would make tests running on virtualized platforms less useful. The package does have not failing autopkgtests right now The package can not be well tested at build or autopkgtest time because CI environments are not well suited to testing GStreamer beyond what is tested already at build time and by the upstream. Hardware configurations are particularly of relevance for the regressions likely to crop up in GStreamer. To make up for that, a test plan has been drafted as is available for review in https://wiki.ubuntu.com/DesktopTeam/TestPlans/GStreamer - the desktop team have committed to execute this on new package uploads and releases. [Quality assurance - packaging] debian/watch is present and works debian/control defines a correct Maintainer field This package does not yield massive lintian Warnings or Errors Find results of `lintian --pedantic` attached 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 be installed by default, but does not ask debconf questions higher than medium Packaging is complex, but that is ok because there's no alternative. GStreamer is a complex project. [UI standards] Application is end-user facing, Translation is present, via standard intltool/gettext [Dependencies] The dependencies for gst-plugins-extra1.0 are, libc6 (>= 2.14) libdrm2 (>= 2.4.98) libglib2.0-0t64 (>= 2.81.1) libgstreamer-plugins-base1.0-0 (>= 1.26.0) libgstreamer-plugins-extra1.0-0 (>= 1.26.4) libgstreamer1.0-0 (>= 1.26.0) libva-drm2 (>= 1.8) libva2 (>= 2.21.0) Which are all in main. check-mir doesn't work for proposed packages. [Standards compliance] This package correctly follows FHS and Debian Policy [Maintenance/Owner] The owning team will be desktop-packages and I have their acknowledgment for that commitment The future owning team is already subscribed to the package (the source package, yes, the binary package is yet to be created) This does not use static builds This does not use vendored code This package is not rust based The package has been built within the last 3 months in the archive Build link on launchpad: https://launchpad.net/ubuntu/+source/gst- plugins-bad1.0/1.26.4-1ubuntu1 [Background information] The Package description explains the package well Upstream Name is GStreamer Link to upstream project: https://gstreamer.freedesktop.org/ I have uploaded a PPA for the new -bad package here: https://launchpad.net/~charles05/+archive/ubuntu/gstreamer/+sourcepub/17606161/+listing- archive-extra The corresponding -good package (which drops the manually vendoring now proposed for -extra): https://launchpad.net/~charles05/+archive/ubuntu/gstreamer/+sourcepub/17606157/+listing- archive-extra To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/2121050/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
