[MIR] pi-bluetooth

[Dave Jones]

[Availability]
The package is already in multiverse (although it's just a bunch of BSD-licensed shell-scripts, it depends on linux-firmware-raspi2 which is also in multiverse).

[Rationale]
The package is required for correct operation of the bluetooth module on the Raspberry Pi 3 and above.

[Security]
I am not aware of any open CVEs against the scripts in pi-bluetooth.

[Quality assurance]
The package is installed by default on Raspbian, and frequently used in Ubuntu (although not installed by default). There is no meaningful test suite included in the package, but the package is regularly exercised by the devices cert team in their image testing.

[UI standards]
The package contains no meaningful user-interface; it's purely a couple of scripts and a udev rule to correctly initialize the bluetooth module at boot time.

[Dependencies]
The package depends on bluez, which is already in main, and linux-firmware-raspi2, which is the subject of a separate MIR (LP: #1867813).

[Standards compliance]
The package installs its scripts under /usr/bin, its udev rule under /lib/udev/rules.d, and a couple of systemd services.

[Maintenance]
The package is maintained by the Ubuntu Foundations team.

[Background information]
This package is a dependency of the new raspi-common seed; the intention is to install this by default in all pi-related images going forward.

[Christian Ehrhardt  (paelzer)]

FYI - the MIR for linux-firmware-raspi2 is in bug 1867813

[Christian Ehrhardt  (paelzer)]

Confirmed bluez in main
 bluez | 5.55-0ubuntu1 | groovy | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Full Depends:
 Depends: bluez, linux-firmware-raspi2 (>= 1.20190215-0ubuntu2)

Ok, agreed as reported to those details, starting a review now ...

[Christian Ehrhardt  (paelzer)]

[Summary]
The package is small and doesn't have much that would conflict with our
policies. It doesn't even trigger any of the checkboxes that would imply
a security review.
The only drawback is that it is severely outdated and our Delta not upstreamed
I'd ask you to work on that, once that is done it should be fine to be promoted.

Required TODOs:
=> The current release should be packaged (0.1.15 ours is two years outdated)
   Along that please upstream our Delta and then remerge the result of that.

Recommended TODOs:
=> Given what the services are doing I wonder if they should not be of
   type=oneshot. I'd ask to spend some time and maybe discuss with the upstream
   to ensure this works as we'd want. Currently we have one "simple" and one
   "forking" but both seem to run a few commands and then exit.
   What states are these services in on a booted RPi, would it be more
   reasonable with type oneshot.

MIR Team Ack (under the constraint of being updated)

List of specific binary packages to be promoted to main: pi-bluetooth

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this except those already in progress
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a (continuous) daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- 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)

[Common blockers]
OK:
- does not FTBFS currently
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard
- no new python2 dependency
- Python package that is using dh_python
- Go package that uses dh-golang

Problems:
- does have a test suite that runs at build time
- does have a test suite that runs as autopkgtest
=> This was already outlined in the report (thanks) and is covered by the
   regular tests of the devices cert team.

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking not applicable for this kind of code.
- Upstream update history is (good/slow/sporadic)
- Debian/Ubuntu update history is (good/slow/sporadic)
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

Problems:
- d/watch is not present and might be a reason updating was missed
- the current release is packaged
  0.1.10 which we have is two years old by now, but there are 5 later releases
  which read like valid improvements fixes.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (only service/udev/shell)
- no use of sudo, gksu, pkexec, or LD_...

[Christian Ehrhardt  (paelzer)]

FYI: Incomplete and back to the reporter (for the version update) but otherwise good.

[Dave Jones (waveform)]

Updated test package now being built in the following PPA:

https://launchpad.net/~waveform/+archive/ubuntu/pi-bluetooth/+packages

I'll work on upstreaming our delta, but one thing to be aware of is that most of the changes aren't actually a delta and can't be upstreamed. Specifically, the changes in debian/rules and debian/compat, which clean up a few lintian warnings *can* be upstreamed, and I'll open a ticket for those.

However, the changes in lib/udev/rules.d/90-pi-bluetooth.rules are actually copies of these rules from the etc/udev/rules.d/99-com.rules file in the raspberrypi-sys-mods package upstream (https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-sys-mods/) which is a collection of various raspberry pi related settings, many of which which can't (easily / directly) incorporate into Ubuntu. Those rules, however, are necessary to make the Bluetooth UART work (and coincidentally set up aliases for the serial console UART when that is enabled, which is presumably why they're in raspberrypi-sys-mods upstream and not pi-bluetooth).

[Launchpad Janitor (janitor)]

This bug was fixed in the package pi-bluetooth - 0.1.15ubuntu1

---------------
pi-bluetooth (0.1.15ubuntu1) groovy; urgency=medium

  * Merged new upstream version (LP: #1897920)

pi-bluetooth (0.1.15) buster; urgency=medium

  [ Phil Elwell ]
  * bthelper: Change BT address with hcitool instead
  * bthelper: FIX: Only run for onboard BT modems

pi-bluetooth (0.1.14) buster; urgency=medium

  [ Phil Elwell ]
  * bthelper: Add the ability to set the Pi BDADDR

pi-bluetooth (0.1.13) buster; urgency=medium

  [ Phil Elwell ]
  * bthelper: Force reinitialisation to allow Secure Simple Pairing

pi-bluetooth (0.1.12) buster; urgency=medium

  [ Phil Elwell ]
  * bthelper: Recognise Pi 4 OUI (#10)

pi-bluetooth (0.1.11) buster; urgency=medium

  * Don't override the BT address on Pi 4
  * Update control file for Buster

 -- Dave Jones <email address hidden> Thu, 15 Oct 2020 01:29:19 +0100

[Christian Ehrhardt  (paelzer)]

Thanks for bringing in the new version Dave!
But this didn't "fix" this bug, only the package promotion will.
So I'm resetting to incomplete.

[Christian Ehrhardt  (paelzer)]

All IMHO strictly required steps are done (new version and we just marked the dependent firmware package as ready for promotion). Therefore MIR Team Ack (and security not needed on this case).

Do you want to:
a) address anything else around the services and/or the upstreaming of that delta before this is complete (please add links if you already started that)?

OR

b) do you want to continue on that asynchronously?

In the latter case (b) I think we are ready on this bug. Therefore If you want set it to Fix Committed and ask an archive admin to do the promotion.

[Dave Jones (waveform)]

Definitely option b) given the current timescales :) I'll upstream the minor packaging delta later this week (ref: comment 5), but unfortunately there's a couple of other release blockers I need to deal with first.

[Iain Lane (laney)]

laney@dev> ./change-override --suite groovy --component restricted pi-bluetooth ~/dev/canonical/release/ubuntu-archive-tools
Override component to restricted
pi-bluetooth 0.1.15ubuntu1 in groovy arm64: multiverse/misc/optional/100% -> restricted
pi-bluetooth 0.1.15ubuntu1 in groovy armhf: multiverse/misc/optional/100% -> restricted
Override [y|N]? y
2 publications overridden.