6 ms·
There are 2 types of "any script you haven't read, or binary you haven't decompiled": 1. scripts and binaries you obtained from somebody you trust in a safe aut
by xkxx 10y ago
There are 2 types of "any script you haven't read, or binary you haven't decompiled": 1. scripts and binaries you obtained from somebody you trust in a safe authenticated way; 2. everything else.
When I update my Debian distro, I get binaries via HTTP, that's true. But I also have the public keys of my distro's maintainers whom I trust. The authenticity of every binary I download is automatically checked using those public keys. It's an example of "any script you haven't read, or binary you haven't decompiled" type 1.
curl | sh via HTTP is an example of "any script you haven't read, or binary you haven't decompiled" type 2.
curl | sh via HTTPS is an example of something that is very-very close to "any script you haven't read, or binary you haven't decompiled" type 1.
- scrollaway 10y agoThe presence of https prevents most mitm vectors. It doesn't prevent the far more likely scenario of the website in question being broken into and serving malware or backdoorware. Point is, don't run binaries you don't have some way of vetting. curl sh is no worse offender than "download link here".
- xkxx 10y ago> don't run binaries you don't have some way of vetting Thank you for your recommendations regarding operational security. We do really appreciate them.
- sctb 10y agoPlease comment civilly and substantively on Hacker News or not at all. https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- xkxx 10y agoThe comment I was replying to was not and is not substantive and informative at all. I wanted to communicate my displeasure to the comment's author, because I'm a mere human. Because I didn't have enough karma yet, I couldn't just downvote it and move on. (NH's policy regarding downvotes from new users encourages them to post unnecessary comments.) That's why I decided to notify the comment's author that his comment was very informative and interesting, even though it was not the case. It's called irony. Is irony uncivil? I don't think so. I do agree that my comment was not substantive, just like the comment I was replying to. That's why I kindly ask to delete that comment too, like you deleted mine. Of course, I expect my request to be most likely ignored, because I'm not some karma [redacted] like the person I was replying to. In fact, I hope I will never become a karma [redacted]. I hope I will always post anything I believe should be posted, regardless of my expectations of being upvoted or downvoted. Thanks for your attention.
- grzm 10y agoIt's called irony. Is irony uncivil? When criticizing someone, it's important to take even more care to be civil, and to do your best to ensure there's little chance of being misinterpreted. One can easily interpret what you consider irony to be snark, which is definitely uncivil. In my opinion, if one is truly trying to be civil, the response here would be more along the lines of an apology for being unclear and misunderstood, rather than defending the action. As for your comment being deleted, that was not the action of any single individual (and from my experience, definitely not a mod): it's the result of actions of a number of users in the community. Asking for others to take action on a particular comment—yours or otherwise—goes against HN guidelines.
- xkxx 10y ago> that was not the action of any single individual (and from my experience, definitely not a mod): it's the result of actions of a number of users in the community Judging by how fast my comment above got deleted, it's definitely a mod or a group of mods. By "mod", I mean any privileged user. BTW, that comment was not uncivil and it was also substantive: I raised an important issue about the HN community. Yet it got deleted. > the response here would be more along the lines of an apology for being unclear and misunderstood I don't think there's any sense in apologizing when everything I say gets deleted.
- kelnos 10y agoDo you never install any software outside Debian's main apt repos? Never add a 3rd-party apt repo for anything that maybe you didn't trust as much? Never clone a git/hg/svn/etc. repo from somewhere and build & install the software yourself? Ok, let's say you don't do any of that. The Debian developers are still fallible, and they certainly don't audit the source code of everything they package. Sure, you have to trust something, and I'll certainly agree that it's more reasonable to trust the Debian packagers (and their distribution infrastructure) than a lot of other things, but saying "curl | sh" (when you're curl'ing over https at least, from a website you can reasonably expect not to be compromised) is always bad is a bit extremist. At any rate, the shell script you download is there for you to inspect before running, and if you're not happy with it, you don't have to run it. Personally, my main beef with that sort of thing is that I want to know if the script is going to accidentally clobber any existing files, or install things to a location where I might not prefer them to be installed. Edit: I'm only now realizing that the OP has you curl from a non-TLS webserver, which I imagine is the first thing that got you upset. Ugh. Asking people to install something that way is just irresponsible.
- eeZah7Ux 10y ago> The Debian developers ... don't audit the source code of everything ... Strawman. If an amount of critical code is audited (and it is) it's still much better than nothing. > I want to know if the script is going to accidentally clobber any existing files Packages are tested on various hosts and architectures. The packaging system check for files being overwritten and that the package can be removed cleanly Also suspicious things (e.g. unsecure file permissions) are checked. Sandboxing tools are often used to contain daemons. Furthermore the package content is tracked, while "curl | sh" cannot guarantee that the same script will be received every time or by every user.
- kelnos 10y ago> Strawman. If an amount of critical code is audited (and it is) it's still much better than nothing. Is it, though? I'm specifically thinking about the Debian fiasco a few years ago when a packager broke OpenSSL's key generation. Clearly less scrutiny is paid than one might think. I'm unable to find any evidence/documentation/anything that suggests that code audits by Debian packagers of critical packages are done regularly (or ever). I did find a few links to some Debian-specific tools to aid code auditing, but nothing to suggest where they're used, how often, and on what packages. Regardless, they look more like linters and static analyzers -- nothing that would help you discover backdoors or just flat-out malicious behavior. > The packaging system check for files being overwritten... Yes, I'm well aware, not sure why you're bringing this up. I was merely pointing out (regardless of any other argument being made) that file-clobbering is a reason why "curl | sh"-style installation bothers me, personally, much more than possible security considerations, which I consider to be overblown.