Let me thank you for such a well prepared MIR case. All I came up with was already answered in the original report \o/.
Review for Source Package: showtime [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. I was torn, but I really could not find much it would process itself. While a security review is always good to have I consider it optional here. List of specific binary packages to be promoted to main: showtime Specific binary packages built, but NOT to be promoted to main: n/a Notes: Required TODOs: - #1 drop the dependency on gir1.2-gst-plugins-bad1.0 (and bring back one to gir1.2-gst-plugins-extra1.0 once LP: #2121050 is resolved) Recommended TODOs: - #2 This switch from one to the newer playe would be the moment to think about isolation features. It is not a service, and apparmor rules might be hard as it is supposed to play video files from anywhere. But would it need to write anywhere? I know usually the approach is default deny and allow a few but maybe here the approach could be default allow but deny some clearly non needed things? Similarly, capability dropping or any such. This is very optional, but worth a look at least as it would be great if it would be possible. And while the actual decoding is in gstreamer so most attacks would be there, some defense in depth if broken there would be great. Consider this non-blocking please. [Rationale, Duplication and Ownership] There is no other package in main providing the same functionality, sure totem is, but this is intended to switch one for the newer other. A team is committed to own long term maintenance of this package. The rationale given in the report seems valid and useful for Ubuntu [Dependencies] OK: - no other build-time Dependencies with active code in the final binaries to MIR due to this - no -dev/-debug/-doc packages that need exclusion - No dependencies in main that are only superficially tested requiring more tests now. Problems: - There are other runtime Dependencies to MIR due to this, but you are already aware of gir1.2-gst-plugins-bad1.0 and I agree that a more fine grained split into gir1.2-gst-plugins-extra-1.0 for those that are more reasonable is a good approach. But ultimately you need to put -bad down to be a suggest and can introduce a depends or recommends to -extra once it exists. [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 Problems: None [Security] OK: - history of CVEs does not look concerning but let us be honest, it is too new to have them. - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not parse data formats - I was first assuming otherwise but it really seems to not parse/, decode, or extract the video itself. It does all that through URLs and Gstreamer objects which is great as it is not yet another attack surface AFAICS. - does not expose any external endpoint (port/socket/... or similar) - 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 not process arbitrary web content (not directly, but who knows where such files are from) but gladly it does not parse/handle it itself (see above yet delegates all to a proven library which is the right approach) - this does not makes appropriate use of established risk mitigation features, on the lib we would say "it is the lib it can't" but here we would know better. I've added a non-blocking suggestion about that. - btw it isn't a classic daemon service, but it is a dbus registered service but that has no impact to our judgement AFAICS. [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. - no new python2 dependency - Python package, but using dh_python Problems: - does not have a non-trivial test suite that runs as autopkgtest, but really it is mostly a new gui wrapper on gstreamer. In theory one could say for all the accelerations a multitude of HW is needed, but that would be non-proportional to what we usually require. I'm glad to see that a, albeit basic, test plan was already defined in https://wiki.ubuntu.com/DesktopTeam/TestPlans/Showtime and think that is sufficient. [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking not applicable for this kind of code. - debian/watch is present and looks ok - Upstream update history is okay for the time it exists, no long term future data known - Debian/Ubuntu update history is ok, same as upstream for the short time it exists. - 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 rather clean (and I mean very clean) - It is not on the lto-disabled list Problems: None [Upstream red flags] OK: - no Errors/warnings during the build - 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 - part of the UI, desktop file is ok - translation present for quite some languages (50ish) Problems: None -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2115912 Title: [MIR] showtime To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/showtime/+bug/2115912/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
