zbentley
12 hours ago
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.
trollbridge
11 hours ago
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.
ikidd
4 hours ago
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.
ivanjermakov
12 hours ago
> 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.
zbentley
12 hours ago
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.
wmehanna
7 hours ago
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...
j45
12 hours ago
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.
zbentley
12 hours ago
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.