Review for Source Package: lenovo-wwan-unlock
[Summary]
I’m not ready yet to give a MIR team ACK: there are some opened question on the
required TODOs that should be answered or resolved. Alongside this, there are
also some recommended TODOs.
To not delay this further, I’m requesting a security review, so that they can
review the apparmor profile in more depth than I did. I’m unsure about what
additional checks they are generaly doing on non opensource software. I’m
subscribing to the package to follow along the answers to my questions.
List of specific binary packages to be promoted to restricted:
lenovo-fccunlock, lenovo-cfgservice
Notes:
Required TODOs:
- There are multiple shared libs without soname in /usr/lib
(/usr/lib/libconfigservice350.so, /usr/lib/libconfigserviceR+.so,
/usr/lib/libmodemauth.so). Are they really shared library being used by 3rd
parties (I think dlopened without -dev package)? If so, they would need symbol
tracking. If not, I suggest probably shipping them under /opt and either using
RPATH or LD_LIBRARY_PATH on their corresponding services?
- While the services have some apparmor profiles, the systemd services
themselves don’t have the initial systemd confinement. It would be good to at
least have a look for potential restrictions being set at the systemd level too.
- The lintian output marked as Error should be cleaned up. As they are all
about having binaries in /opt, a lintian override with a comment taken from the
rationale of the description would be great.
Recommended TODOs:
- There are multiple other warnings in the lintian output. Some of them, like
the -dbgsym package not shipping debug symbols could be fixed by bypassing
-dbgsym generation. Others that are not in our control could be overridden to
mute the warning.
- Why unpacking under debian/temp, while in case of multi-binary packages, the
install target is automatically set to debian/tmp? I would suggest using
debian/tmp to conform with the multi binary packages. This would help simplify
the debian/rules files (no need for cleaning manually for instance).
The package should get the team (canonical-mainstream) subcribed to the
bug before being promoted
[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.
The rationale given in the report seems valid and useful for Ubuntu
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- SRCPKG 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
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard
- Does not include vendored code
Note:
- There is no source code in the package but it’s shipping binary firmware and
services. The goal is to ship it to restricted.
[Security]
OK:
- history of CVEs does not look concerning
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
xml, json, asn.1], network packets, structures, ...) from
an untrusted source.
- 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, ...)
Problems:
- does run a daemon as root
- while the services have some apparmor profiles, the systemd services
themselves don’t have the initial systemd confinement. It would be good to at
least have a look for potential restrictions being set at the systemd level
too.
[Common blockers]
OK:
- does not FTBFS currently
- 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:
- are partner engagements and a test plan or code
- no new python2 dependency
[Packaging red flags]
OK:
- Ubuntu only package
- debian/watch is not present but also not needed (see rationale)
- 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
- It is not on the lto-disabled list
Problems:
- There are multiple shared libs without soname in /usr/lib
