Don’t download this. It’s a curl | bash installer for a binary whose sources appear to just … be the popular FOSS bluez btproxy tool, which it downloads and builds, and whose binaries are checked into the repo. But those binaries could just as easily be malware, and every Linux distribution under the sun has bluez as a first-class package.
Assuming that this repo is well intentioned, this should have been a blog post on how to install bluez for your platform and use its proxy tool, with some shell one liners provided to make that easy. Not a curl | bash installer for something totally opaque, which turns out to be another project’s software basically renamed into this repo.
This is not the way. Also potentially a license or trademark/name issue.
There’s a big difference between executing something from your package manager—and bluez is packaged by literally every major distribution—and executing:
a random binary from a brand new GitHub repo (which you didn’t build and can be swapped out for something evil any time)
…that’s actually a different project’s binary rebuilt and renamed/redistributed (or malware)
…as root
…on a hypervisor.
So yes,
> It's always about trust in author and distributor
Is totally correct. There are different levels of trust. This repo merits very low trust.
What's valuable is someone figured out and shared one way of doing it, their way, and I don't think it was asserted that it was the best or the only way.
Lots of folks use community scripts, or use them as inspirations to build their own.
A community script is fine. A community script which redistributes opaque binaries that are actually renamed builds of an unrelated project with an incompatible license via curl | bash is not.
At best it indicates a lack of awareness of package managers’ value and convenience (and probably distributes binaries that only work on the owner’s distro to boot). At worst it encourages dangerous install practices and/or distributes malware.
A blog post (“here is how you install bluez and run a couple of systemd units that pipe Bluetooth to your VM”) is both more useful for users whose setup differs from the author, less sketchy license- and malware-wise, and more educational. If you want a prepackaged bash tool that automates that too, go nuts. Just don’t vend other people’s software in curl | bash binaries in your repo.
Hi HN, I built this after hitting a wall with Bluetooth passthrough on Proxmox: Intel's onboard Bluetooth/WiFi combo chips (BE200, AX210, AX211, and others) are built so only the machine that boots them can drive them. Hand the chip to a VM via USB passthrough and it wipes its own firmware, no setting fixes it. It's how the hardware works. Also flaky on gaming distros like ChimeraOS/Bazzite even with add-on dongles :-/
Instead of fighting passthrough, this keeps the adapter on the Proxmox host, let's share it into the VM over the local network via BlueZ. 2 simple commands: run the installer on the host, run it again inside the VM pointing at the host's IP. The VM sees a normal Bluetooth adapter and pairs like usual. Both sides auto-reconnect on reboot.
Works for game controllers in a gaming VM, Home Assistant BLE sensors, headphones, anything that expects a normal adapter.
I would be happy to answer questions about the approach.
Most BT adapters clear their firmware and need reinitialized when enumerated on USB. USB passthrough, properly configured, is transparent to the adapter. You should simply need to run the correct drivers with the correct firmware package inside your guest.
I've had no problem passing through the same card to a full fat Manjaro VM. The WiFi was flaky last time I tried, but the Bluetooth was always fine.
Don’t download this. It’s a curl | bash installer for a binary whose sources appear to just … be the popular FOSS bluez btproxy tool, which it downloads and builds, and whose binaries are checked into the repo. But those binaries could just as easily be malware, and every Linux distribution under the sun has bluez as a first-class package.
Assuming that this repo is well intentioned, this should have been a blog post on how to install bluez for your platform and use its proxy tool, with some shell one liners provided to make that easy. Not a curl | bash installer for something totally opaque, which turns out to be another project’s software basically renamed into this repo.
This is not the way. Also potentially a license or trademark/name issue.
> But it could just as easily be malware
Everything that can be downloaded could easily be malware. No users verify binaries/compile from line-by-line verified source.
It's always about trust in author and distributor. Curl | bash or AUR or build from source - matters very little.
There’s a big difference between executing something from your package manager—and bluez is packaged by literally every major distribution—and executing:
a random binary from a brand new GitHub repo (which you didn’t build and can be swapped out for something evil any time)
…that’s actually a different project’s binary rebuilt and renamed/redistributed (or malware)
…as root
…on a hypervisor.
So yes,
> It's always about trust in author and distributor
Is totally correct. There are different levels of trust. This repo merits very low trust.
What's valuable is someone figured out and shared one way of doing it, their way, and I don't think it was asserted that it was the best or the only way.
Lots of folks use community scripts, or use them as inspirations to build their own.
A community script is fine. A community script which redistributes opaque binaries that are actually renamed builds of an unrelated project with an incompatible license via curl | bash is not.
At best it indicates a lack of awareness of package managers’ value and convenience (and probably distributes binaries that only work on the owner’s distro to boot). At worst it encourages dangerous install practices and/or distributes malware.
A blog post (“here is how you install bluez and run a couple of systemd units that pipe Bluetooth to your VM”) is both more useful for users whose setup differs from the author, less sketchy license- and malware-wise, and more educational. If you want a prepackaged bash tool that automates that too, go nuts. Just don’t vend other people’s software in curl | bash binaries in your repo.
Or just buy a $15 dongle instead of the crap interference-laden onboard BT and have problem-free USB passtrough as well.
It is a little bit weird to me having a rule of first unauthenticated client side request winning here
Eh, he probably hit Fable’s guardrails when he promoted “secure this project”
Hi HN, I built this after hitting a wall with Bluetooth passthrough on Proxmox: Intel's onboard Bluetooth/WiFi combo chips (BE200, AX210, AX211, and others) are built so only the machine that boots them can drive them. Hand the chip to a VM via USB passthrough and it wipes its own firmware, no setting fixes it. It's how the hardware works. Also flaky on gaming distros like ChimeraOS/Bazzite even with add-on dongles :-/
Instead of fighting passthrough, this keeps the adapter on the Proxmox host, let's share it into the VM over the local network via BlueZ. 2 simple commands: run the installer on the host, run it again inside the VM pointing at the host's IP. The VM sees a normal Bluetooth adapter and pairs like usual. Both sides auto-reconnect on reboot.
Works for game controllers in a gaming VM, Home Assistant BLE sensors, headphones, anything that expects a normal adapter.
I would be happy to answer questions about the approach.
Most BT adapters clear their firmware and need reinitialized when enumerated on USB. USB passthrough, properly configured, is transparent to the adapter. You should simply need to run the correct drivers with the correct firmware package inside your guest.
I've had no problem passing through the same card to a full fat Manjaro VM. The WiFi was flaky last time I tried, but the Bluetooth was always fine.