Point is, don't run binaries you don't have some way of vetting. curl sh is no worse offender than "download link here".
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.
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.
Do you mean an organized group of users who are downvoting? If so, I haven't seen evidence of such a group on HN. There is a strong reaction by many community members to what's perceived as uncivil behavior, as the HN community as a whole values the quality of the forum.
By "mod", I mean any privileged user.
The HN mods are dang and sctb. They are indeed privileged users, as they have the ability, among other things, to ban users. They've also got a lot of responsibility, which they take very seriously and with — from my perspective — great care.
You're admittedly new to participating on HN (or at least this is a new account). Please take some time to reflect on the community reactions to your comments, and how your personal views of civility and substantiveness may differ from those of the community as a whole. This goes as well for assumptions of how the community works and behaves. This isn't meant as a value judgement of your views, just that they appear to differ, if at least a little. After all, this is the community you'd like to participate in. You can also observe how others behave on the site to better understand community standards.
Please take this in the spirit it's intended. As one HN user to another, I'd like for you to have a positive experience as well as contribute constructively to HN.
If you have questions that aren't answered by the guidelines and FAQ, you can contact the mods by email (see the contact link in the footer). I've also found general search engines (e.g., DuckDuckGo, Google) and the HN search tool (in the footer) very useful to find answers to many questions I've had about the HN community.
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.
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.
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.
Only the official repos, yes, because anything else would be insecure.
> Never add a 3rd-party apt repo for anything that maybe you didn't trust as much?
Heck no, never, ever. Not even once. That's insanely foolish. Frankly, I view, 'please add my PPA/repo to install' as a different way of saying, 'I don't know enough about security for the software I write to be installed on your computer.'
> Never clone a git/hg/svn/etc. repo from somewhere and build & install the software yourself?
I view that as somewhat different, given that the source is there and has a weakly-cryptographically-secure history (weak because it's SHA1), so that if someone ever did something bad then it'd be easy to prove it.
How do you end up dealing with things that aren't packaged for your distro? Do you end up downloading source, doing some checks to whatever level makes you comfortable, and package yourself? Or do you mostly either not find yourself in that situation, or just take an "oh well, I'll deal without it" attitude.
I use a few 3rd-party repos, though ones that I would consider more trustworthy than a random PPA (for example, Google's Chrome apt repo). I certainly don't trust them as much as Debian's official repos (but, again, I'm not sure how much that trust is actually rational!), but I'd consider it unlikely that Google would get compromised or slip something nasty in (and even if they did, it's not like the Chromium source in the Debian repo has been audited).
> I view that as somewhat different, given that the source is there and has a weakly-cryptographically-secure history (weak because it's SHA1), so that if someone ever did something bad then it'd be easy to prove it.
That's all well and good, but that sounds like an after-the-fact reactionary thing. It's little comfort to be able to prove something bad happened after you've been owned.
I just feel like most of desktop security, even on Linux is on pretty shaky ground, and we greatly overestimate the care we take when installing software. I think you're probably ahead of most people by using only official repos, but it's like the classic analogy of a chain with a single weak link: all it takes is one "git clone" of something that does something malicious, and that's it. Sure, the probability of a successful attack is reduced by avoiding 3rd-party repos, etc., but attack possibilities are still very much there, and it feels like people don't seem to see that.
But, overall, yeah, the state of desktop security wrt software installations is so much better on nearly any Linux distro than common practice on Windows or macOS, it's crazy.
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.