Thank you for the review Myles. I addressed the comments in,
https://salsa.debian.org/gstreamer-team/gst-plugins- bad1.0/-/merge_requests/22/diffs?diff_id=504697&start_sha=6ec805cc9363ccfbd0df2c394f34eb63b44ae2f1 -- 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: Incomplete 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
