Package: release.debian.org
Severity: normal
X-Debbugs-Cc: rust-asahi-bts...@packages.debian.org, noisyc...@tutanota.com, 
cybae...@web.de
Control: affects -1 + src:rust-asahi-btsync
User: release.debian....@packages.debian.org
Usertags: unblock

Please unblock package rust-asahi-btsync

[ Reason ]
asahi-btsync is a command-line application plus systemd service that allows
users to sync bluetooth keys between macOS and linux (specifically, via bluez)
on Apple Silicon machines. Recently [1], upstream received multiple reports
that if the program is executed in a state where macOS was never paired to any
bluetooth device, or more generally where the 'BluetoothUHEDevices' nvram
variable is unset, asahi-btsync will panic and exit with an error.

This behavior was first reported to Debian in the past, see Bug#1071216 [2]. At
the time we decided not to act upon the bug in agreement with upstream and the
reporter because all of us believed this to be an (unidentified) issue with the
user's machine. However, my assessment of the bug has changed now -- see the
'Impact' section below -- and now I do believe this bug should be fixed in
trixie. Accordingly, I have reopened the bug and set its severity to important.
The undesired behavior was patched upstream [3] and the patch could be
backported cleanly to the version currently in testing. Therefore I closed the
bug by a new upload to unstable which includes the patch.


[ Impact ]
The command-line application panicking is not a big issue in and of itself:
fixing it mostly has an aesthetic purpose as it avoids a very bad-looking error
message and a useless exit error. This is one of the reasons why we could
ignore [2] in agreement with the reporter and upstream in the first place.
However, some time after [2] was closed, we started shipping the asahi-btsync
service to sync bluetooth keys automatically. asahi-btsync.service is a static
unit started by udev when installed on Apple Silicon machines. The addition of
the unit to the asahi-btsync package, together with reports proving this bug
affects more than one user, substantially change my assessment of this bug and
of its impact.

If the patch is not applied, users running Debian on Apple Silicon whose
coexisting macOS installation (always expected to be present, as running linux
on Apple Silicon machines in only supported in dual-boot configurations) was
never paired to bluetooth devices, or whose 'BluetoothUHEDevices' nvram
variable is unset for other reasons, will likely have the asahi-btsync systemd
service fail on their system until such a pairing is done, or until the nvram
variable is set. The service cannot be disabled since, as I said, it is a
static unit managed by udev. To avoid the service failure, the affected users
will be forced to mask the service or the udev rules that trigger it. This
situation must be avoided.

To make things worse, asahi-btsync is installed as a recommended package by the
asahi-platform metapackage maintained by the Bananas Team, which is the
recommended way to install the userspace asahi (linux support for Apple
Silicon) software on Debian. Therefore, asahi-btsync can be expected to be
installed on a relevant fraction of Apple Silicon machines running Debian. In
particular, the asahi-btsync service can be expected to be running on these
machines.

[ Tests ]
No automated tests. The undesired behavior is triggered by a state of the
machine which is for the most part not under the control of the Debian
installation.

[ Risks ]
I believe there are little to no risks: all the (trivial) patch does is
adding a check that the nvram variable exists, and exiting cleanly if it
doesn't. The only downside I can see to this approach is the user won't be
warned the nvram variable is unset, but this is far more acceptable than
having a service permanently failing on some users' machines.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
rust-asahi-btsync is not currently subject to a block, but it won't be able to
migrate to testing before May 15th and has no autopkgtests, so it will be fully
frozen after that date and will never migrate without an unblock.

[1] https://github.com/AsahiLinux/asahi-nvram/issues/38
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071216
[3] 
https://github.com/AsahiLinux/asahi-nvram/commit/5986b7891ca30311d946e91ed382d6d5758a12aa

unblock rust-asahi-btsync/0.2.4-5
diff -Nru rust-asahi-btsync-0.2.4/debian/changelog 
rust-asahi-btsync-0.2.4/debian/changelog
--- rust-asahi-btsync-0.2.4/debian/changelog    2025-04-29 00:53:59.000000000 
+0200
+++ rust-asahi-btsync-0.2.4/debian/changelog    2025-05-10 13:21:06.000000000 
+0200
@@ -1,3 +1,11 @@
+rust-asahi-btsync (0.2.4-6) unstable; urgency=medium
+
+  * Package asahi-btsync 0.2.4 from crates.io using debcargo 2.7.8
+  * d/patches: add avoid-no-variable-panic.patch to avoid a panic when
+    no BluetoothUHEDevices nvram variable is set (Closes: #1071216)
+
+ -- NoisyCoil <noisyc...@tutanota.com>  Sat, 10 May 2025 13:21:06 +0200
+
 rust-asahi-btsync (0.2.4-5) unstable; urgency=medium
 
   * Package asahi-btsync 0.2.4 from crates.io using debcargo 2.7.8
diff -Nru rust-asahi-btsync-0.2.4/debian/patches/avoid-no-variable-panic.patch 
rust-asahi-btsync-0.2.4/debian/patches/avoid-no-variable-panic.patch
--- rust-asahi-btsync-0.2.4/debian/patches/avoid-no-variable-panic.patch        
1970-01-01 01:00:00.000000000 +0100
+++ rust-asahi-btsync-0.2.4/debian/patches/avoid-no-variable-panic.patch        
2025-05-10 13:21:06.000000000 +0200
@@ -0,0 +1,29 @@
+From 5986b7891ca30311d946e91ed382d6d5758a12aa Mon Sep 17 00:00:00 2001
+From: Sasha Finkelstein <fnkl.ker...@gmail.com>
+Date: Sat, 3 May 2025 17:26:30 +0200
+Subject: [PATCH] Do nothing if there is no variable present
+
+Closes: #38
+---
+ asahi-btsync/src/main.rs | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/src/main.rs b/asahi-btsync/src/main.rs
+index 1d16d6e..28b2d14 100644
+--- a/src/main.rs
++++ b/src/main.rs
+@@ -85,9 +85,11 @@ fn real_main() -> Result<()> {
+     file.read_to_end(&mut data).unwrap();
+     let mut nv = nvram_parse(&data)?;
+     let active = nv.active_part_mut();
+-    let bt_devs = active
+-        .get_variable(bt_var.as_bytes(), VarType::System)
+-        .ok_or(Error::VariableNotFound)?;
++    let bt_devs = if let Some(var) = active.get_variable(bt_var.as_bytes(), 
VarType::System) {
++        var
++    } else {
++        return Ok(());
++    };
+ 
+     match matches.subcommand() {
+         Some(("list", _args)) => {
diff -Nru rust-asahi-btsync-0.2.4/debian/patches/series 
rust-asahi-btsync-0.2.4/debian/patches/series
--- rust-asahi-btsync-0.2.4/debian/patches/series       2025-04-29 
00:53:59.000000000 +0200
+++ rust-asahi-btsync-0.2.4/debian/patches/series       2025-05-10 
13:21:06.000000000 +0200
@@ -1,3 +1,4 @@
 update-metadata.patch
 relax-dep.diff
 remove-unused-argument.patch
+avoid-no-variable-panic.patch

Reply via email to