[MIR] lenovo-wwan-unlock

[Dirk Su]

[Availability]
The package lenovo-wwan-unlock build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64
Link to package https://launchpad.net/ubuntu/+source/lenovo-wwan-unlock

[Rationale]
 - The package lenovo-wwan-unlock is required in Ubuntu restricted for WWAN hardware support
 - The package lenovo-wwan-unlock 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.
 - It would be great and useful to community/processes to have the
   package lenovo-fccunlock and lenovo-cfgservice in Ubuntu restricted, but there is no definitive deadline.

[Security]
 - No CVEs/security issues in this software in the past
 - no `suid` or `sgid` binaries
 - Binary configservice_lenovo and DPR_Fcc_unlock_service in /opt/fcc_lenovo/ is no problem because AppArmor constraints applied
 - Package does install services, timers or recurring jobs
   lenovo-fccunlock.service
   lenovo-cfgservice.service
 - Security has been kept in mind and common isolation/risk-mitigation
   patterns are in place utilizing the following features:
   AppArmor constraints had been included:
   - opt.fcc_lenovo.DPR_Fcc_unlock_service
   - opt.fcc_lenovo.configservice_lenovo
- Packages does not open privileged ports (ports < 1024).
- Packages does not expose any external endpoints
- Packages 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
   - https://github.com/lenovo/lenovo-wwan-unlock/issues
 - The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]
 - The package does not run a test at build time because it contains only binary files

 - The package can not be well tested at build or autopkgtest time
   because it will need real hardware for testing. To make up for that:
   - We have access to such hardware in the team
 - Based on that access outlined above, here are the details of the
   test plan
      execute service by systemd command
   sudo systemctl start lenovo-fccunlock
   sudo systemctl start lenovo-cfgservice
   and (if already possible) example output of a test run:
     - output of lenovo-fccunlock: https://pastebin.ubuntu.com/p/nsFBW3jXDk/
  - output of lenovo-cfgservice: https://pastebin.ubuntu.com/p/8rCFqRHQ8V/
   We will execute that test plan
   on-uploads

[Quality assurance - packaging]
 - debian/watch is not present because it is a native package and need to add
   AppArmor configs
 - debian/control defines a correct Maintainer field

 - This package does not yield massive lintian Warnings, Errors
 - Please link to a recent build log of the package
   https://launchpad.net/ubuntu/+source/lenovo-wwan-unlock/2.0.0-0ubuntu1
 - Please attach the full output you have got from
   `lintian --pedantic` log: https://pastebin.ubuntu.com/p/Mm6CX7QgFc/
 - 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 not be installed by default

 - Packaging and build is easy, link to debian/rules
   https://git.launchpad.net/~dirksu/+git/lenovo-fccunlock-sar/tree/debian/control

[UI standards]
 - Application is not end-user facing (does not need translation)

[Dependencies]
 - No further depends or recommends dependencies that are not yet in main

[Standards compliance]
 - This package correctly follows FHS and Debian Policy

[Maintenance/Owner]
 - The owning team will be canonical-mainstream and I have their acknowledgement for
   that commitment
 - The future owning team is already subscribed to the package

 - This does not use static builds
 - This does not use vendored code
 - This package is not rust based

- The package was test rebuilt in PPA or sbuild recently
  PPA: https://launchpad.net/~dirksu/+archive/ubuntu/fccunlock-test

[Background information]
 The Package description explains the package well
 Upstream Name is lenovo-wwan-unlock
 Link to upstream project https://github.com/lenovo/lenovo-wwan-unlock

The package is in multiverse so this is a request for promotion to 'restricted' instead of to main.

[Christian Ehrhardt  (paelzer)]

Hi,
thank you for filing - but we feel this is a bit immature to already get MIR approval already.

This should go through normal review & sponsorship into multiverse first, to give us a chance to see it in action and trigger concerns and tests in the real place.

It is also rushed as it is late to Noble ... :-/

So the next step IMHO is to get a reviewer from e.g. ~ubuntu-sponsors get their feedback, improve on all they find. And once through that you can set it back to NEW to get a review.

[Jeremy Bícha (jbicha)]

Please file a separate bug for sponsoring into multiverse and subscribe ubuntu-sponsors to it.

[Lucas Kanashiro (lucaskanashiro)]

I am unsubscribing ~ubuntu-sponsors for now.

[Jeremy Bícha (jbicha)]

lenovo-wwan-unlock is now in Ubuntu so I'm resetting the status to NEW

[Didier Roche-Tolomelli (didrocks)]

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 co...

[Mark Esler (eslerm)]

Please use Ubuntu Security Team (~ubuntu-security) for MIR tasks. Security Engineering is not part of (and does not monitor) the Canonical Security Team (~canonical-security).