Review for Package: cups-browsed [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 package is running as root, with an ungated (protected by apparmor, but not restriction on the systemd service itself). As the code within the package this is originated from has greatly changed over the years and when it entered main, we even didn’t have a MIR process, I suggest that this package is audited by our security team. Assigning to them, but let’s not that block the required and recommended todos that you can work in parallel to the security review. Only the source package needs promotion, as this package is a transition from another source. Required TODOs: - There are no package build time tests nor autopkgtests in the package which is a requirement for entering main. I know you mention that before this wazs already the case. However, this should have been addressed when we raised the bar in quality for packages in main and it seems the right opportunity to gate on having at least an initial autopkgtests testsuite with strong indication of improving it in the near future. - Remember to subscribe the desktop-packages team as I think it will be the official team owning the packages so that list of criticals bugs can be adressed. - The package does install one service, gated with apparmor. However, additional permission on the service would be great. See the MIR template on which ones to add like reduced permissions, temp envronment, restricted users/groups... Due to this service running as root and as this requires a security review too. Recommended TODOs: - This package do not ship library or symbol files, however, it has this in debian/rules, which is useless for that package: override_dh_makeshlibs: dh_makeshlibs -- -c4 This could be cleaned. - I suggest that you revisit the lintian override about file permission on the executable, if you look at , there is no security gain by this permission set. It should be 0744 if you don’t want other users to be able to execute it. [Duplication] This is a transition from some older package, no package will duplicate this functionality. [Dependencies] OK: - no other Dependencies to MIR due to this - cups-browsed checked with `check-mir` - 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 - not a go package, no extra constraints to consider in that regard - not a rust package, no extra constraints to consider in that regard [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 privilege port/socket - does not parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source. - 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, ...) Problem: - The package does install one service, gated with apparmor. However, additional permission on the service would be great. See the MIR template on which ones to add like reduced permissions, temp envronment, restricted users/groups... [Common blockers] OK: - does not FTBFS currently - no new python2 dependency Problems: - There are no package build time tests nor autopkgtests in the package which is a requirement for entering main. I know you mention that before this wazs already the case. However, this should have been addressed when we raised the bar in quality for packages in main and it seems the right opportunity to gate on having at least an initial autopkgtests testsuite with strong indication of improving it in the near future. [Packaging red flags] OK: - See the rationale on the presence of the package in Debian. It will be in sync as the rest of the cups stack. - d/watch is present and looks ok (if needed, e.g. non-native) - Upstream update history is good - 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 (but see below) - d/rules is rather clean (see comment below) - It is not on the lto-disabled list Problems: - This package do not ship library or symbol files, however, it has this in debian/rules, which is useless for that package: override_dh_makeshlibs: dh_makeshlibs -- -c4 You can clean it. - I suggest that you revisit the lintian override about file permission on the executable, if you look at , there is no security gain by this permission set. It should be 0744 if you don’t want other users to be able to execute it. [Upstream red flags] OK: - no incautious use of malloc/sprintf (as far as we can check it, but quite hard due to image parsing, hence the security review needed) - no use of sudo, gksu, pkexec or LD_LIBRARY_PATH - no use of user nobody - no use of setuid - no warning/bugs during build. - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - not part of the UI for extra checks - no translation present, but none needed for this case