Hacker News Reader

The installer makes unexpected change that you wouldn't know how to revert (and that you would need to) unless you read at the code.

It feels like we have gone back to the Windows 95's regedit era.

I resent that these kinds of installer have become the norm.

That's the equivalent of "just run with sudo". People don't want to deal with different configurations, policies, etc. So to provide a "one-click" Installation, they'll just change the whole environment to whatever they think they need. Good luck installing multiple such programs.

It's like homebrew making /usr/local itself and everything in it all owned by whatever user installed homebrew for years until Apple finally just took over the directory.

"most macs are really single user anyway"

Really? That's the excuse? I'm supposed to feel good about software coming from this quality engineering?

How to not sell your "enterprise" software to me. Have documentation that includes curl https://something.your.tld/install.bash |sudo bash.

That's a hard no. If you think that's a good idea what other shortcuts have you taken in your software development lifecycle?

From experience, they've built a company on SaaS and your data will soon be everyone's data.

That's almost universal for non-package based installation instructions on Linux, to be fair. And it is safer than "add this trusted repo to your list of repositories", since at least it's one time, not something that will be accessed every time you run "$PACKAGE_MANAGER upgrade".

A lot of the time the script being sudo bash'd adds repos as part of its installation process.

That's also true, but that's more of a problem with the script itself, not the way you run it.

There's no guarantee that their shell script doesn't also add their repo to your list of repositories, and in fact many do - I've written scripts just like that that do.

I trust an application that wants me to add it's repos to it - It's pretty clear what it's doing, I can see and verify the package installation after it's done, and I can order my package manager to download the packages before installing them, inspect the package contents, and then install them afterwards. It's been demonstrated numerous times that it's easy to determine[1] whether a shell script is being downloaded via curl or executed via curl | bash ; That provides an opportunity for attackers to serve you different data if they think you're paying attention or not.

But quite simply: Setting up a package repository is a professional operation and a professional concern. It's not hard hard, but it's not so simple. What it does is speak to a level of professionalism and integration - They company has decided that they will stick to your package manager's conventions, rather than invent it themselves. That's humility. That's what I want from a company that I buy from.

[1] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

So you don't bother to read the source before running when it's open?

How is that any different from running npm which is even harder to audit with many dependencies?

OS packages may have maintainers and some eyes before being packaged but for other ecosystems where people can just upload, it seems it's on the same level.

There are known attacks that can detect if your curling into bash vs. just curling/downloading which can change the script being delivered[1].

So yeah read it all you want, just don't curl it and pipe it to bash.

1. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

> I was actually with them until

> "In fact, the Kitten installer does just this."

100% agree

> Even if there's a confirmation

There isn't, if your sudo is set up to cache credentials and you have sudo'ed something recently enough [0]:

  # Reduce unprivileged ports for this session...
  sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80 2>&1 1>/dev/null

It could be polite to `sudo -k` before that, so people who use NOPASSWD sudo (and I guess don't care as much about security on that machine) don't have the speedbump whereas people who would otherwise have to type their password indeed end up typing their password.. but still, this is too much for an installer.

Just print something to stdout, make it red if you want, and include a note in the documentation to the same effect.

While I was looking, I saw this a few lines down:

  sudo chmod 0777 "${sysctlConfigurationFilePath}"

sysctl.conf(5) on my system doesn't say anything about what mode bits files in /etc/sysctl.d need to have, but +x is not often used for configuration files. I haven't looked further, but this is a smell.

[0] https://codeberg.org/kitten/app/src/commit/7ca1f8a4d191f3a81...

[1] https://codeberg.org/kitten/app/src/commit/7ca1f8a4d191f3a81...

+x isn't as concerning as world-writable. This basically allows any user to escalate to root privileges through exploiting sysctl parameters like kernel.modprobe (albeit after a reboot).

...and that's coming from someone who has audacity to comment on and criticize well-established security practices because they find them inconvenient.

Wow.

For the record, this isn't just "a smell". This is effectively a (likely unintended) backdoor for any user to gain root privileges. Any kind of user-based separation becomes moot at that point.

dns runs on port 53. the rpcbind service on 111. pop and imap, both privileged, even with ssl enabled can take usernames and passwords.

making this sort of change in any installer script is a terrible idea.

Yeah, I'm not touching this with a ten-foot pole.

Software that changes my system configuration for their own benefit is something I try to avoid for eternity. I wouldn't trust such a development team to make smarter choices in the future.

Exactly. The quickest way to have your software put on the shitlist at any organization of any size by it's security team is to do something exactly like this.