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.
I’d really like to see an end to curl | sh installers. The harness vendors are all notoriously bad about this. OAI, Grok, Claude - all “recommend” installing this way.
Oh-my-pi recommends installing via bun and I give it points there for not promoting this absolute rubbish.
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.
You were right about the licensing and it was sloppy of me. The binary is BlueZs btproxy and the repo just had a blanket MIT sitting on top of it. That just go fixed and is now: GPL-2.0-or-later is disclosed properly, along with the LGPL-2.1 and BSD-2-Clause parts it links. I have completely missed that ecc.c is BSD-2-Clause and requires its notice to ship with binary redistributions; my bad. the install.sh script now writes the notice and a source offer to disk and releases carry the license texts next to the binary instead of leaving them in git where nobody installing it would looked.
On the opaque binary, the CI now rebuilds it from the kernel.org bluez-5.66 tarball inside a pinned debian:bookworm container and fails if a single byte differs from what's committed!
The tarball's checksum is pinned too otherwise the whole thing rests on whatever the download happened to return. There is a oneline docker command in the README if you want to verify it yourself rather than take my word for it ;-) I also added a MANUAL_INSTALL.md which is moer or less the blog post you suggested... build btproxy from source and write the two units by hand -> no script and no binary from me!
One correction to my own docs while I'm here: Id written that btproxy isnt packaged anywhere. That was wrong! Accoreding to my reading, Arch ships it in bluez-utils. Its Debian, Ubuntu and Fedora that donesn't which happens to be Proxmox and the guests this is for...
Also fixed a few things the review shook loose, including a bug where the port restriction I added could be bypassed with a /0 CIDR while still reporting itself as locked down.
Lastly, you said the repo merits very low trust. That's fair! And it's the right default for any new repo asking for root on your hypervisor and so mine included. Pinning the hash and making the build reproducible isn't me trying to convince you that I'm trustworthy. Its so that it doesn't have to matter...
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.
I’d really like to see an end to curl | sh installers. The harness vendors are all notoriously bad about this. OAI, Grok, Claude - all “recommend” installing this way.
Oh-my-pi recommends installing via bun and I give it points there for not promoting this absolute rubbish.
Exactly like all the "community-scripts" that were started by a fellow that passed away a couple years ago.
I've been railing against the install one-liners for years to obviously poor effect.
> 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.
You were right about the licensing and it was sloppy of me. The binary is BlueZs btproxy and the repo just had a blanket MIT sitting on top of it. That just go fixed and is now: GPL-2.0-or-later is disclosed properly, along with the LGPL-2.1 and BSD-2-Clause parts it links. I have completely missed that ecc.c is BSD-2-Clause and requires its notice to ship with binary redistributions; my bad. the install.sh script now writes the notice and a source offer to disk and releases carry the license texts next to the binary instead of leaving them in git where nobody installing it would looked.
On the opaque binary, the CI now rebuilds it from the kernel.org bluez-5.66 tarball inside a pinned debian:bookworm container and fails if a single byte differs from what's committed!
The tarball's checksum is pinned too otherwise the whole thing rests on whatever the download happened to return. There is a oneline docker command in the README if you want to verify it yourself rather than take my word for it ;-) I also added a MANUAL_INSTALL.md which is moer or less the blog post you suggested... build btproxy from source and write the two units by hand -> no script and no binary from me!
One correction to my own docs while I'm here: Id written that btproxy isnt packaged anywhere. That was wrong! Accoreding to my reading, Arch ships it in bluez-utils. Its Debian, Ubuntu and Fedora that donesn't which happens to be Proxmox and the guests this is for...
Also fixed a few things the review shook loose, including a bug where the port restriction I added could be bypassed with a /0 CIDR while still reporting itself as locked down.
Lastly, you said the repo merits very low trust. That's fair! And it's the right default for any new repo asking for root on your hypervisor and so mine included. Pinning the hash and making the build reproducible isn't me trying to convince you that I'm trustworthy. Its so that it doesn't have to matter...
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.