Show HN: Proxmox -> Share your host's Bluetooth with a VM over the network

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

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.

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.