> Javascript plus a "curl | sudo sh" attitude to life equals "yeah no, I am never touching this thing".
I get why there are people that don’t like how some installers do this, but this trope is really turning into the “but I don’t even own a TV” of OSS commentary.
Just use the Docker image if you don’t like it. Or get their appliance which actually supports ongoing development.
I wasn’t even aware this was a supported installation method anymore. If it is, it’s hidden on the site. When was the author’s last experience with homeassistant?
If the answer to cloud enshittification is “I know! I’ll use a different company’s solution instead of this open source project because I want to make an outdated stand against curl|bash” then I think the thought process is misguided.
HomeAssistant has changed officially supported installation methods so much, I personally don't know what's supported. Docker, tarball, installer, their own OS Part 1, etc were all different ways you can run it.
Last I checked, the bare metal pip3 method was "always" going to be supported. So the "Just use Docker" comments ignore this.
The author complains about a lack of product leadership at Phillips, but HA has always been renown for ignoring their users.
I put HAOS on an RPi4, plugged in a Zigbee/Z-Wave adapter, and never looked back. It runs 15ish Sengled RGB bulbs wonderfully, I've got all sorts of lights macro'd and timer'd (e.g. porch light comes on at sunset, turns off at midnight). Reliability is crazy, the UI is wonderful, I can access it from all sorts of devices and native apps...and there's a few other devices it sucks in too (air filter, Chromecasts, my NAS health, etc.) Now I haven't done any of the other actually useful projects I have in my backlog (thermostat, motion sensors, security cameras), but I'm extremely confident that HA can handle any that I throw at it.
All that being said, I find it a little odd that this article is somehow decrying HAOS as a worse alternative to a proprietary, anti-user black box developed by companies trying to squeeze more profit, just because they played fast-and-loose with some shell scripts at some point. (Aside: I just installed Homebrew on a new Mac today, and it's still just a curl | sh)
Most of the major consumer IoT vendors have had major security incidents (Wyze, Hue, Nest, Arlo, many others), and if nothing else, my little HAOS Rpi gets a little obscurity compared to the big names getting hit by script kiddies. Not to mention it's easy for me to keep it local-only and just join it to my Tailscale network.
But given all the allusions to HomeKit, I suspect the author has total faith in Apple to do it right (not a wholly misplaced assumption) and wants everything to just talk HomeKit.
Which we might actually get (in practice) as Matter makes inroads! Hell, I'd love for everything to talk HomeKit because HA can emulate a HomeKit Controller, and that means less cloud APIs. Win for everyone!
HAOS has been a pretty good experience when I set it up at my parents house though. I don't begrudge HA from trying to figure out the most reliable way to support installation methods - they're in a complicated space, and techies like us do tend to build unique-snowflake home setups.
I'm running the docker container (since I already had a home server running docker containers), but a NUC with HAOS for my folks has been working great.
I do begrudge them for putting in placeholders for features for years that weren't functional. Like a map that was blank and entire sections that weren't functional. I also begrudge them for doing things like removing Python 3.7 support 1.5 years before it was EOL. I begrudge them for re-architecting entire features like Open Z-Wave three times over the five years I used them. I begrudge them for asking their projects be removed from other open source projects.
HA is one guy's pet project to goof around with the latest and greatest technologies.
Yea; I run HomeAssistant via the official Docker container and have been pretty happy with it. It's only accessible on my local network, and my phone/laptop/etc use Wireguard to talk to it if I'm somewhere else.
Once you’re kind of settled there take a look at NodeRED. Integrates really cleanly with Home Assistant and for most of the kinds of people on HN that are already technically inclined, it makes much more complex automations and integrations a piece of cake.
Note that you don't need the Community Store if you're running HA via Docker.
Every plugin that is in that store must have a custom_components folder.
Drop that into the bind-mounted volume holding HA's configuration.yaml and restart. HA will pick it up automatically, and you'll be able to install it in Integrations and Devices.
Yep this is how I'm doing it. Combined with ESPHome I've got a nice, local-only automation system using sourceable off-the-shelf parts (but I'm so, so happy that Athom are making open-source flashed IoT devices - which go and live on my IoT network).
Also, no one’s forcing you to pipe curl into sudo sh. I don’t think a software project listing this as an installation method is that big of a red flag to be honest.
Why is "sudo" emphasized so heavily, anyway? Running as your ordinary user, that shell script can send someone your session cookies, authenticate with your SSH agent, and really anything that you can do. Sure, maybe not running as root protects the integrity of the OS and prevents some persistent keylogging attacks, but honestly... you don't need a keylogger when you just grab the cookies, or install your own binaries farther up in the path (good old ~/.local/bin/firefox instead of /usr/bin/firefox).
Frankly, being anything other than super paranoid is almost a little reckless.
Also, shit-talking Home Assistant is a pretty weird take. I wouldn't write it in Python configured half in YAML and half in SQLite either, but ... not having to write it myself was the fun part.
Anyone who really complains about curl | sudo is just doing it for nerd points, because I guarantee you they happily install all sorts of other software without "vetting" it.
And if someone caught someone doing trickery it'd be big news.
There are those of us who are security minded and will in fact download the script and check the sha1/sha256 and review the script before running it. Any time I see this curl sudo thing is when there's always another (manual) option. The shell scripts themselves aren't so complex that you can't figure out what they're doing, they're normally fairly straightforward, unless they were generated by some tool, or are in fact malware, so you can see if something looks funky before you run it. Sure, there can be a malware that makes it so you can't tell, but normally not.
If I don't trust the website to do curl | sudo bash then why do I trust the software that I would eventually install?
Even the old argument of "middleware devices modified the script en-route" is mostly removed by HTTPS everywhere.
And there are people like you who actually look at the script (and the compiled code, too!) to find things, because if they do find something in a script as big as HomeAssitant, they'll be famous.
I don't use any of this home automation junk, but this kind of begs the question - why would such an app need root access to your devices in the first place?
Shit gets complicated, and being able to dynamite a railroad track through a mountain of nuance is just easier.
"Oh, that path is actually not a temp directory and requires permissions different than the user account?" - sudo
"Oh your firewall blocks my outgoing telemetry data?" - sudo
"Oh your firewall blocks my localhost request but I don't actually realize that's what happens but when I try it with sudo it just works everywhere?" - sudo
There are myriad reasons apps want root access, and almost none of them are good reasons, but that doesn't mean it's not simpler for them to get sudo from a user than it is to get dev eyes addressing (let alone understanding) the nuance.
I think the downvotes might be because I specifically said outbound connections? Although if you have IoT devices it's not unreasonable that they should be able to initiate conversations with your other devices (that would then need permission to accept inbound connections from your IoT devices).
Or maybe the downvotes are because everything I was saying was conjecture / hypothetical anyway, and you're now asking a more specific question to the general question being answered.
I thought the question was "why do apps that don't need sudo request sudo?" And my answer was "perhaps because it's easier to fix permissions problems by getting permission for everything than it is to get them by understanding why your app is getting blocked by them in the first place." Whether it's inbound or outbound or taking video surreptitiously doesn't really answer the question of "why, if the app doesn't actually need it?"
At any rate, I don't actually know why because I don't ask for permissions that I don't need. I also don't know why you're getting downvotes as I didn't downvote you: this answer, like my previous one, is speculative, as is somewhat inevitable when trying to answer "why" questions that relate to the motivations of others.
For the record, I thought your original answer was excellently well constructed. The bulldozer analogy is completely recognizable to anyone who's tried to engineer any software that needed to run a local server and somehow get its data out. Geez why didn't we all think of forcing the user to run it as root? /s
Maybe more interestingly: I do think that the motivations of others are totally calculable. Society is an autocomplete. One big honkin LLM replete with all the hallucinations. Pretending to be a member of this society is to pretend that I wish to better understand why I'd be downvoted for a thought - to pretend that it's just me, a neuron, looking for back propagation. Yay for the neuron.
Yeah, that's a conceivable use case for a dedicated box, I guess. But why would that be necessary (or desirable?) Seems like opening port 80 would be the last thing you'd want a home appliance to do... lol
80 is desirable because it’s the default port of web browsers and means you can just visit the DNS or up address & not have to remember to tack on some arbitrary port number. Or use some sort of proxy if setup.
And there’s nothing wrong with using port 80 security wise. Binding a port doesn’t mean you’re opening it on the firewall for the world to see. Plus if you’re opening some port on the firewall, what port you use doesn’t matter - it’ll be scanned by an automated scanner shortly regardless of port.
The downsides of choosing port 80 for your all-important lightbulb dimmer switch telemetry are that:
1. browsers don't even attempt encryption,
2. the port could be open to the world, and
3. lots of people are already running more meaningful shit on port 80.
Seriously, you want to sell me a lightbulb that needs root access and then opens an unencrypted port and then makes outbound calls...? Are you nuts? That's beyond lazy design. It's almost like an intentional insult.
[edit] If you set up a home service on your local network, surely you can also bookmark the obscure port number next to the 128/ address in front of it. The only purpose served by turning your light bulbs into a beacon from hell on port 80 would be letting strangers totally penetrate your house. What happens if you start up a webserver? Do the lights go off?
1. OK, but it's a LAN - who cares. It's either that or you're in self signed cert hell anyway.
2. If that's the case you have major issues going on which are irrelevant to the port chosen
3. On a single IP - so what? Every device can open it's own port 80 on your LAN without any conflict
> Seriously, you want to sell me a lightbulb that needs root access and then opens an unencrypted port and then makes outbound calls...? Are you nuts? That's beyond lazy design. It's almost like an intentional insult.
This doesn't make any sense. Are you talking about a single light bulb or actual orchestration software? Both need to communicate to actually do anything.
> edit] If you set up a home service on your local network, surely you can also bookmark the obscure port number next to the 128/ address in front of it. The only purpose served by turning your light bulbs into a beacon from hell on port 80 would be letting strangers totally penetrate your house.
This also doesn't make any sense. There is no reason a device on your local network listening on port 80 makes it a 'beacon from hell' - because again, listening on LAN & WAN are 2 very different things. And the port it's using has 0 bearing on security.
> What happens if you start up a webserver? Do the lights go off?
Absolutely nothing - because again there is no conflict with different devices on your LAN using the same ports to listen on.
You're mixing up a number of different things here & making issues where there aren't any. A device on your network opening port 80 doesn't magically make it accessible to the world for poking & prodding or result in any conflicts that cause things to stop working.
And when it comes to orchestrators like Home Assistant - you can choose any port you so desire. But changing the port doesn't make it any less or more secure.
Tbh, I’m put on more on alert by the spelling errors in the linked post than I am by the ostensible threat of a server timing my requests in order to serve malware.
It’s good practice to check anything that you’ll pipe to `sudo`, but this article’s level of paranoia is kind of self-defeating, no?
At some point, we all trust the things we run on our machines. We rely on communities — and our participation in them — to vet installations.
There is no perfect solution. Someone will always be misled.
Maybe I’m just a naive idiot, but I thought her point was not the danger of sudo’ing random shell scripts per se but any sort of “solution” to restore the prior capabilities of a consumer product that required that level of technical acumen.
But every single other reply seems to be either “well yeah obviously read the script first” or “how dumb, just use docker,” so like I said, maybe I’m the dumb one.
I mean its really putting all the onus on the buyer of the product in the hopes that they have technical capabilities or alternatively just stilling all the benefits to the corporate company. Sad state of play.
Microsoft.. The only company I have ever heard mention CRIME and BREACH and invokes their specter in .Net to do awesome things like.. Not let you enable websocket compression in SignalR.
Of course Microsoft is fine with it - the official Windows way of installing things has forever been "Pssst, hey there, why don't you download this .exe and run it and keep pressing ok until it's done"
How is this much different than how a deb or something gets installed? Actually, Windows installers are expected to be signed by default and it'll warn you if they aren't.
people act weird around any kind of script, more-so than executables, i've never really understood it.
I periodically get told that a published browser userscript of mine is malicious or suspicious in emails simply because of the cautions and wording around the userscript installers themselves (it's just a css tweak, a theme), meanwhile the executables I have in the wild have generated zero similar feedback.
my theory is that since the script is more easily read that it attracts people to read it without any theory or knowledge of what they're even looking at .
Even if you don't review it before running it, after
$ curl https://whatever/foo.sh > foo.sh
$ sh foo.sh
if something goes terribly wrong you can examine foo.sh to try to figure out what happened and how to fix it. Even if foo.sh managed to delete itself you can just grab it again.
After
$ curl https://whatever/foo.sh | sh
if something goes wrong and you then try
$ curl https://whatever/foo.sh > foo.sh
to get a copy of the script to examine a malicious server can tell that you aren't piping to a shell [1] and give a non-malicious script.
Since it takes an insignificant amount of effort to defend against this why not get in the habit of doing it?
I don't like how HAOS is the only currently-supported way to use the SkyConnect to get Zigbee + Matter support currently, and messing with firmware on the SkyConnect was exactly the opposite reason why I got one in the first place. It doesn't "just work", even for just ZigBee, and now I've sunk hours into troubleshooting it without a working ZigBee setup in HA. Meanwhile, the Sonoff ZigBee bridge worked flawlessly the first time setting it up with my phone and their eWeLink app.
Smart Home 2023Q3 status: still for hackers only if you want more than a few lightswitches that you can just toggle from your phone, and even if you do want that, stick to one vendor + system only.
After a few days with ZigBee I was ready for an extended vacation. Finally got rid of the whole thing and everything is on a dedicated WiFi network now that is an integral part of the house, in other words: if I sell this house that WiFi network + all HA stuff goes with it including a nice manual of how it all hangs together.
Highly recommended: Shelly gear, it is easy to configure and seems to be rock solid, I've got a bunch of their remote control radiator valves, several remote control relays and a tri-phase consumption/production meter. It all worked flawlessly since installation. And instead of a regular Pi I got one that was built into a keyboard. It was mostly because I couldn't get a bare one but in the end I think this was the better option.
> if I sell this house that WiFi network + all HA stuff goes with it including a nice manual of how it all hangs together
I had something similar. Rock solid. Wired back haul. Nice manual. I knew it wouldn’t add $$$ to the house but I was a little surprised to find out it actually put a lot of people off. It had negative value as I had to rip it out and go analog.
Even nerds looking at the house wanted to do their own thing not maintain someone else's ideal and normies refused to spend ANY mental energy on understanding it.
That could well happen, so, for that eventuality I have a little cardboard box with the old radiator valves and thermostat. The solar panels and the inverters would be a bigger issue though, this all runs locally, not in the cloud (it was a bit of a job to find inverters that do not require a cloud connection, what a nonsense that is). But given that altogether these give the house its A++++ energy label (it is in the top .1% or so for houses of this size and age with respect to energy consumption) I'm pretty sure that buyers would be A-ok with it. Energy efficiency is a massive factor in people's buying decision here (as well as location and general state of the house, obviously).
But your point is well taken and I'll be sure to introduce the subject at the handover if it ever comes to that.
Here it's a mandatory disclosure item and it's important enough that you can filter by it on the real estate listing sites. More so because now house insulation comes with a mandatory 'bat study' requirement which is absolutely bonkers. So houses that are already energy efficient are at a premium.
What also helps is that the whole system runs without any user intervention. The manual is mostly aimed at people hired to add stuff at some point in the future, or in case something breaks.
Recently set up HA with a Zigbee dongle, took less than 15 from zero (newer used HA before) to be able to control my dimmer, most of that time was spent on finding my USB device path in /dev.
Connect the usb dongle, start docker container, initial HA setup, find my Zigbee device and done.
Wait a few months. My HA Zigbee integration works great… most of the time. Sometimes it loses all the devices and I have to reboot. Never found the time to dig into why.
Can’t confirm, the only issues I’ve had were with Deconz, since switching to Zigbee2MQTT (using the same ConBee stick) there have been no issues whatsoever.
If you know where to find the mesh view of your zigbee network, the one that has all of the links between the nodes rendered using bezier curves, at the bottom of that page there are three icons. The first icon is called Network, and if you view that page there should be an option for editing the channel That the zigbee network is on.
Tapping that option should bring up a dialogue that lets you migrate to a different channel with a warning about how some devices may not automatically migrate and will need to be removed and re-added if so.
I bought a cheap ConBee (is that what it’s even called?) Zigbee USB dongle, plugged it in, passed it through to my HA container, and it’s flawless. Plenty of things you can knock HA for, but good ZigBee support is easily attainable. I have…a large setup. 30 lights, door locks, ZigBee switches, blah blah blah. And I’m not smart guy. Such an improvement over WiFi
I think if you stick with Homekit certified accessories you can probably have a multi-vendor setup that's OK. Homekit can be flaky at times, though, and I would definitely recommend Home Assistant instead if you are a hacker.
+1 for the HUZBZB-1. I waxed more poetically about my setup already[1], but I've had that little guy for over 4 years, it was plug-and-play on day 1, and I've never had a single issue with a Zigbee or Z-Wave device. (Wi-Fi? don't even get me started...)
And yeah, it'll be another year or two before Matter/Threads really starts picking up steam. I'll just pick up a new dongle when there's 10 of 'em in that same timeframe.
(Disclaimer: my house is 800 sqft and I don't share any walls with neighbors. Zigbee is SUPPOSED to be mesh and Just Work assuming you have enough devices, but I can't speak from experience on that front.)
I definitely have a small setup, but getting ZigBee running was fairly straightforward. Two steps: 1) buy a ConBee dongle and 2) install and setup Zigbee2MQTT.
This is even better than the docker version, because it's able to set up a bunch of stuff for you that you'd have to do manually with docker, like the current ZWave integration.
I think her point is that managing your home automation through this level of involvement is not the end goal she’s looking for. I may be wrong, but it sounds like she wants stuff to plug in and work without having to go down the road of setting up custom automation stitching stuff.
I love Home Assistant, but I regularly find myself opening the Hue and Lutron apps anyway. And I’m someone who runs a NUC. I don’t mind administration, but I don’t want to HAVE to do that when I’ve already paid for a thing that supposedly does most of that.
Has anyone actually been hacked by a curl|bash installer because of the curl-bash-iness of it (and not a theoretical PoC--I'm well aware of those blog posts)?
Yes, exactly the point I was trying to make. curl | sudo bash is just making it obvious what the glossy GUI installer with its dialog boxs and animated progress meters is doing anyway.
I get why there are people that don’t like how some installers do this, but this trope is really turning into the “but I don’t even own a TV” of OSS commentary.
Just use the Docker image if you don’t like it. Or get their appliance which actually supports ongoing development.