[zbentley]

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]

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.

[wmehanna]

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...

[zbentley]

Thanks for replying and working to improve the project! All of the below is just, like, my opinion, man; I'm not any authority on what you should or should not do, just someone who uses computers a lot.

> 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!

That's a good first step. The problem with distributing arbitrary binaries is that I have to continue to trust that you, your CI system, and whoever has or gets access to your GitHub repo adhere to that statement in the future. It's regrettably common these days for good binary artifacts to get replaced later on with malware--either due to a maintainer selling out, losing their keys, or a compromise of e.g. a GitHub CI component/docker image/whatnot.

Lots of people rely on artifacts distributed that way all the time! But it's sub-par, especially given that:

> 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...

...which is fair (I assumed it was part of bluez on other systems; it isn't. My bad!), but also indicates that those systems are really close to having it packaged or package-able. Given that, and the ease of building btproxy, instead of redistributing it I'd recommend either just sharing compile/install instructions (configure/make, just like you have in build.sh) directly to users, or seeing if you can get it packaged for other distros (hard but educational). You of course don't have to do either of those things, but both of those approaches are a lot more common, reliable, and resistant to any compromise of your account/CI that might happen.

At the very least, it's pretty low effort (and potentially useful for others) for you to open issues/email threads on a couple of distros you use to the tune of "would it be possible to add btproxy to the build of bluez you already distribute? Are y'all open to doing that, or is that work someone like me would need to volunteer for?"

> I also added a MANUAL_INSTALL.md which is more or less the blog post you suggested

Looks great! To be clear, automating systemd/config/device enumeration like your install.sh does is common and totally fine; it was just the redistribution of zero-provenance binaries that concerned me. If you tell folks to configure/make btproxy and then have install.sh do all the rest, that seems pretty reasonable to me.

That said, if you'd like to develop expertise in even more reliable/standardized ways to make this "one-click" installable, you could look into packaging it yourself into e.g. RPM/DEB/etc. formats and distributing those from your GitHub repo. Tools like fpm (https://fpm.readthedocs.io) make that a lot more approachable than it once was, and if you ever did decide to work on upstreaming distributions of btproxy, that'd build a lot of the required expertise. Using "real" package formats is also a lot less fragile than some of the other install.sh wrangling, in that dpkg and friends handle e.g. uninstalling, conflicts, transitive dependencies, and so on. "wget http://github.com/whatever/foo.deb && dpkg -i foo.deb" is better than "curl | bash"!

Distributing a tarball/.deb/.rpm also makes it easier to leverage GitHub's release artifacts rather than checking in the binaries and having your scripts refer to the main branch. Using release artifacts takes a couple of steps away from "an account compromise could replace this with malware easily", in that people can refer to old ones and (if they want) verify that they were created at a given time. It's not as good as being in a real package manager (which isn't perfect; xz did happen after all), but better than "curl git@main | bash".

> 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.

Thanks for engaging with that. I stand by it, but also stand by the specific phrasing: the repo's distribution mechanism sketches me out, but you don't! It seems like you're making a valuable tool with good intentions, and please don't let any of my other criticism as to the "how" detract from the truth of that!

I think that "reproducible" builds are only as useful as the trustworthiness of the build infrastructure, which is low in this case (not because you did anything wrong, but because you're not on e.g. DebianMaintainers or whatnot). Given how easy it is to hand-build btproxy, I still think that's the least risky and best-habit-forming set of instructions you can provide, but if you really think your use-case and/or target audience won't work with that, shipping a .deb ain't a bad way to go either.

[ivanjermakov]

> 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]

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.

[ikidd]

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.

[j45]

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]

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.