Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

Why would I bother copying and pasting the code to my clipboard when common industry practice now is just to invoke the output of curl directly?

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)

View on HN

C'mon... That is nothing like the industry standard -- you used SSL.

Watch out. Does curl check the key chain against any key store? I bet not.

Actually it does. You turn off checking via -k

Oh, nice, you are right, should be compiled against OS' key storage. Actually it's wget who often doesn't care of that.

Wget has the --no-check-certificate flag, I've had to use it to work with self-signed certs before.

Um, GNU wget does check the key, and it requires the lengthy `--no-check-certificate` to disable it.

Perhaps busybox wget doesn't check the key? But if you're using busybox, that's a whole other can of worms.

Wget does not validate certificates by default because there's no CA bundle provided with wget. It does check for /etc/ssl/cert.pem, but it doesn't provide one. So you have to provide one or set up /etc/ssl/certs/ as OpenSSL libraries expect.

Curl does provide a CA bundle (/usr/share/curl/ca-bundle.crt) and by default libcurl validates certs against it.

cURL doesn't provide a CA bundle any more [1], it's the job of your OS to provide this. As I understand it, all tools that provide SSL support will fail safe if there are no root CAs on your system. [1] http://curl.haxx.se/docs/sslcerts.html

Though, to be fair:

    $ pacman -Qi ca-certificates | grep 'Required By'
    Required By    : ca-certificates-java  curl  glib-networking  neon  qca  qt4

Note that curl is on that list but wget isn't.

Pacman lists ca-certificates as an optional requirement of wget: https://www.archlinux.org/packages/extra/x86_64/wget/

But the point halfasleep is making is important: Don't assume either wget or curl will validate your SSL connection because it may not have been set up by your OS/distribution.

I wasn't that wrong then. ;)

They do still provide a bundle[1] though, for cases where you need it (eg homebrew's curl-ca-bundle package).

  [1]: http://curl.haxx.se/docs/caextract.html

Touché!

It does if you're on a proper operating system like Debian :)

I dislike this whole trend. How about we start thinking in terms of leaving the user's default environment, and system, alone, and “installing” software into nice sandboxed areas where we can easily enable/disable it, or delete it with a simple “rm -rf directory/path”

I would love to use such a thing!

I'm bugged with programs I don't use anymore which start on system boot. Even after removing some programs, they just don't go away.

A sandboxed environment would be really good to use!

http://www.gobolinux.org/

unfortunately it seems to be dead.

That's just bad administration as even on Windows, you can easily disable them (msconfig). With Linux, this isn't even an issue unless you're blindly installing dozens of daemons (which, again, can easily be disabled) as Linux doesn't have hundreds of application launchers that install themselves like Windows does (again, daemons being the exception).

The only example I can think of where you might run into problems is if your desktop environment is doing some weird sessions. But that's usually fixed pretty easily in the system settings for whatever desktop environment you're running.

This is all pretty basic stuff; you shouldn't need a sandboxed environment to prevent applications from auto-launching unless you're going around installing malware (and if you are deliberately installing malware on your main bare-metal OS, then you're insane).

This may have been true 5-10 years ago, but modern desktops are removing the ability to manage services, sessions, and startup apps easily and clearly.

Unless they're blocking access to [insert your favourite terminal emulator] and deinstalling su, rm and unlink, then they are not removing any such ability.

To be fair, some of this is driven by real needs. People want fast boots, so you have to work tightly in parallel. That requires a clear and complex dependency graph. That requires significantly more than some symlinks in /etc/rc?.d/. Also as distros aim to pare down their default installs, you end up in a situation where there is very little that you actually can disable without breaking your ability to boot.

Furthermore, given typical CPU/RAM overheads on modern hardware, disabling something that takes a fraction of a second to start and consumes almost no RAM can seem slightly pointless!

I'm not familiar with systemd, but upstart takes a similar approach to sysvinit - don't want something to start? Just move it out of /etc/init/ like you would have rm'd the symlink in /etc/rc?.d/ :)

I'm referring more to the GUI sessions, startup apps, etc. It seems when I first started using Linux, most of the DEs made it very clear how to edit menu entries, where startup apps were located, what data and apps were restored when a session was restarted... At least in the Ubuntu variants, those options are less obvious.

Ah right, then yeah, that stuff is now pretty opaque and has changed a bunch since the old desktop days.

> With Linux, this isn't even an issue

That's a problem systemd is trying very hard to solve.

/sarcasm

SysV init may be old, crufty, and inelegant, but it's reasonably straightforward to parse and troubleshoot manually (and BSD-style rc inits are even more straightforward). Making the bootstrap process nondeterministic strikes me as tremendously unwise.

I agree here. I really enjoyed the explicit control granted by sysV. The switch to systemd just seems like fixing something that isn't broken.

I will probably be proved wrong as systemd matures, but right now it's just not the case.

100% both those comments.

I used to be a huge ArchLinux fan but them switching away from their rc.conf model to systemd felt like a real kick in the teeth.

Yeah . . . it looks like Arch has gotten to the point where it just kinda violates all the points of the so-called Arch Way wholesale, even worse than the mainstream (supposedly) Unix-like OSes tend to violate the so-called Unix Philosophy these days.

> I will probably be proved wrong as systemd matures, but right now it's just not the case.

Yeah . . . I doubt it. I made the switch to FreeBSD as my primary OS of choice back in 2005 or 2006 without being 100% certain why I decided to try to live on BSD Unix pretty much full-time right then (there were reasons, but I think the timing of the migration was largely whim). I never even missed the Linux world for the next half decade or so. I then tried living with Debian again for a while (long story why), and I discovered that everything of substance that had gone on in the Linux world since then seemed almost tailor-made to annoy the shit out of me. It was a real shock that destroyed the fondness I still harbored for Debian.

I poked around at some other Linux distributions I hadn't tried, or handn't used in years, and discovered they were even worse -- and systemd is sorta the apotheosis (no relation) of exactly the sort of nondeterministic, "the software knows better than the user" BS that I remembered with severe loathing from my distant past primarily using (and fixing, for a living) MS Windows. Between Red Hat developers like Drepper and Poettering, the agenda of Canonical and Ubuntu, and the GNU project's strange synthesis of superficially opposed concepts like stagnation and invidious undermining of anything related to the (so-called) Unix philosophy of system design, I ultimately came to the conclusion that outside of a professional capacity (that is, writing code and/or managing servers, and that only if I'm paid) I'm simply not interested in screwing around with Linux-based systems any longer.

Your tolerance may be higher than mine but, given your comment about what you dislike about systemd, I rather suspect you'll only grow more frustrated with the direction of Linux development community efforts over time. You might want to think about diversifying your OS experience in the near future (if you haven't already) so you have a place to ready and waiting for you to go when the Linux world has finally pushed you to the point of just wanting to escape.

Offering a random anecdote:

I wasn't particularly aware of systemd's emergence and the squabbling that went on at the time, but I got exposed to it a gen or 2 after it first hit fedora through a fedora centric project. At first I was non-plussed and sort of annoyed that I didn't know how things worked, and primarily relied on the compatibility bridge with service that worked well enough.

At one stage I ended up having to do some tweaking with rc init scripts would have required a fair amount of haks (in the pejorative sense) and since these wouldn't work in systemd i decided it was the time to get to know it.

It only took me a couple of hours to get a good overall sense of the system and mindset, and the minor things I needed to get accomplished ended up being much cleaner in systemd once I "got it".

Once I had a good new mental model of it, I found that I liked working with systemd much more than the old guard. Ignoring the technical and performant advantages, I find the framework for discovering and resolving problems to be much more effective and easy to deal with once you got over the hump of the confusing bits of information overload and changed grammars.

I've never been a huge fan of Lennart Poettering in the way that he seems to optimize for friction in certain communities, but I think systemd is a real step forward and we need people like him to drag up forward kicking and screaming at times.

I user a lot of different posix systems day to say, and it's gotten to the point that I now groan when i have to deal with one still using a traditional init approach.

I'm not saying systemd is without issues, but if you give it some time with an open mind I think you may find out it has a lot going for it (and not just the marketing bullet points - thats part of lennart's problem)

Check out http://www.gnu.org/software/stow/

Homebrew (http://mxcl.github.io/homebrew/) does largely the same thing for third-party source installs on Mac OS X.

You can't just enable/disable software if it depends on other software or vice versa. But your package manager may have facilities for that, like Nix [ http://nixos.org/ ].

To be fair to Homebrew (the example I'm picking on here), it does install to a nice sandboxed area. That area is named "/usr/local", but you can give it its own path and everything works pretty well. (I find I have to completely remove and reinstall Homebrew about every two months, generally because libgettext changed yet again.)

Homebrew is ok, and it has arguably improved the situation on Mac OS X a great deal, but I think we can do better still.

Using homebrew, one tweaks recipes in ruby code until they work.

Why do we not have a common (and widely adopted!) way for software projects to tell other software how to install/uninstall them, and what other projects they depend on for what particular operations (e.g. configure, build, install, test etc), with reusable data rather than code.

Why is (some of) this information captured in bits of ruby, useful for a particular OS X package management system, but not when you want to deploy a similar stack to a IaaS provider where you'll use a different incompatible system like Puppet or Chef to set up the same stuff.

I think we have made this whole situation more complicated and fractured than it needs to be.

Code is reusable data, and regardless of language is much more useful than an arbitrary data format. There was an attempt to port homebrew to linux, but it didn't go far.

dotCloud has just open-sourced Docker[1], an attempt at solving the deployment issue.

[1] http://docker.io

> There was an attempt to port homebrew to linux, but it didn't go far.

Linux already has more package managers than you can shake a stick at. To gain traction on linux, homebrew would have to offer useful features that other package managers don't have. Even then, people are more likely to copy the features into an existing linux package manager.

I don't think people tend to shop around when it comes to package managers; you use whatever your distro provides. If it sucks, you find a better distro or submit patches, depending how involved you are.

I don't know why anyone would want Homebrew on Linux anyway. The whole point of it is that OS X is a mostly-serviceable UNIX without a decent package manager. So if you have a handful of UNIX packages you just want a lightweight way to install them using the system headers where applicable.

But if you need to install tons of stuff the cracks start to show, because you have no conflict resolution or sophisticated versioning. Linux leans heavily on its package managers, so I just don't see what Homebrew has to offer.

Homebrew formulas are much more frequently up-to-date than other package managers due to the crowd-sourced pull-request updates - there isn't a package mantainer that has to do all the work. Formulas are straight-forward and don't have a million conditionals for different system configurations (this would be hard to maintain on linux). These two things already make it much more pleasant to use than apt-get/yum/pacman.

Homebrew seems more akin to Arch's PKGBUILD or Gentoo's ebuilds than other package managers.

Yes, I am familiar with homebrew and use it every day including submitting pull requests back. However you missed the point of my comment. The point is, it's more pleasant until you run into a conflict which existing Linux version managers tend to handle much better (out of experience and necessity). At that threshold of complexity you need something more sophisticated than homebrew to avoid pulling your hair out. OS X benefits from a certain homogeneity that puts homebrew in a sweet spot.

I don't know about "widely adopted", but we do have a common language for expressing how to build/install/test software across Linux, Unix, Windows and OS X:

http://0install.net/interface-spec.html

The tools to read this are in most Linux distribution repositories already (usually under the name "zeroinstall-injector"), and do dependency resolution, conflict resolution (via a SAT solver), GPG signature checking, etc. And each package unpacks to its own directory, so they don't interfere with system packages.

That's not a sandbox. If you have ten programs installed in /usr/local, and you want to uninstall one of them, rm -Rf /usr/local is not the tool for the job. (At least on Linux. I'm assuming UNIX-like Macs are the same.)

Homebrew actually uses /usr/local/Cellar, so rm -Rf /usr/local/Cellar/pypy is what you'd want, except that it won't remove symlinks to /usr/bin, launch scripts and such; you still need some kind of uninstall script (brew uninstall).

Like I said, Homebrew installs in its own directory pretty well. I chose /usr/homebrew, explicitly so I can rm -rf. I think for most Homebrew users their Macs have nothing else in /usr/local and so that's why it's not an unreasonable default.

Changing the prefix still doesn't mean that each app is sandboxed. That is what the parent comment was talking about.

You can't do rm -rf /usr/homebrew/$SOMEAPP/ and know that it is all gone.

I put all my sensitive files under my home directory. Every subdirectory of my home directory is non-world-accessible, and I have a cron job which chmod's world privileges away from new files and directories that don't match a whitelist of directories I wish to publish (e.g. ~/public_html).

I've started giving each application its own user and group, and do the git checkout, compile, and install as that user. (You don't need root for "make install" if you ran configure with the --prefix option.) Then I know it's not going to be able to write anywhere but its own directories, and won't be able to see my browsing activities or sensitive files, because UNIX permissions won't let it. For added security, once the software is built, move it to a location where only root can write, and chown -R root:root.

You can also use VM's for added security. With the new namespaces in 3.8 (the kernel for Ubuntu Raring Ringtail), it should (in theory) be safe to let untrusted software have root in a Linux container (LXC). (LXC is like chroot but you can virtualize stuff like the network, and since the guest uses the host's kernel memory allocator, you don't have to dedicate a block of memory to running the guest as you would with Xen or Virtualbox.)

It sounds like you really want BSD jails.

It seems like you've been putting a lot of effort in, but posix uid/gid isolation is increasingly pourous with the typical desktop environment these days. It sounds like you are ready for real RBAC - if you put the time in selinux (or apparmor or grsec) is leaps and bounds more effective.

uid/gid is generally a sound system, the problem IMO is basically that no one uses it for serious security, so a lot of things are not set up to be properly careful by default.

uid/gid on Linux also is terrible for trying to enforce inheritance. POSIX ACLs help, but they're strikingly poorly documented/supported.

It's called iOS

Like regularly backed up virtual machines?

You are trusting some third-party everytime you download a proprietary or just big open-source app. Even on Open Source, you just have trust in the public review.

In that example you can read the source before, the chances of an evil change just when loading it with your terminal is quite limited, MITM doesn't work that well on SSL, too.

Really sad, especially when something like Chef-client is also installed in a similar fashion [0], one would expect these guys to know better:

    sudo true && curl -L https://www.opscode.com/chef/install.sh | sudo bash

[0] http://wiki.opscode.com/display/chef/Installing+Omnibus+Chef...

Know better... in order to do what? They also provide an APT repository, which you can choose to use instead of the curl command. The curl command exists solely for convenience, because it autodetects your OS, distro version, and automatically registers the right APT repository for you if you're on Debian.

As I've mentioned here (https://news.ycombinator.com/item?id=5508680), people often freak out at curl commands, yet at the same time I've yet to see a viable proposal for an alternative.

Well, the downloaded bash script does all that, and a user is always free to leave the last piping-into-bash command off. They can review it first, and then run as sudo (or whoever) if it passes muster.

It's not that much different, so I don't understand the huge problem. Most likely if tutorial writers added a second step, the user would just copypasta the second step also.

Thankfully I followed this procedure after a co-worker sent me this: `curl -L http://bit.ly/10hA8iC | bash` ... was able to turn my speakers down first ;)

That's one of the better rickrolling I've seen!

One of my mates rickrolled me by post (aka snail mail) just days after I moved house. It took me 2 years to find out who was behind that.

Allow me to show you a viable proposal for an alternative:

http://manpages.ubuntu.com/manpages/precise/man8/apturl.8.ht...

As I've mentioned in https://news.ycombinator.com/item?id=5508680, for any alternative to be viable it must "work on all major platforms". APT is only used in Debian derivatives. How do you want to handle OS X users?

Give them a DMG?

It would be lovely if there was a One True Software Distribution Format, but it's not going to happen. wgetting into a bash script is a terrible way to not really support any users properly :)

Neither is it going to happen that every developer spends considerable resources on creating packages for every platform. Just look at the popularity of curl installs, or even at the number of developers who don't bother to provide binaries and stick to source tarballs.

So you're trusting opscode to provide the primary centralized control system of your entire server ecosystem but you're concerned they might be embedding something malicious in their installer shell script?

Don't get me wrong, i'm no fan of the practice especially sans tls, but this seems like a poor example.

It's not that you don't trust opscode, it's that it's possible that someone could hack opscode's installer script...

just like they could replace a binary, backdoor the Makefile or hide something bad deep in the repo. And of course their hash of their signing key for their apt repo and any shasums are provided on the same webserver.

Of course that is always a risk, but with most FOSS software being maintained in public revision control systems, it's difficult to truly hide something.

Even if you discard the security angle of wget | bash (which you would be a foolish choice) there is the simple problem of repeatability.

If you are deploying 50 new servers and OpsCode releases a new version of Chef after 25 of the servers have performed the wget, the next 25 will get a different client that might be incompatible with the server.

For what it's worth, that curl install is a "beachhead" install. When you provision servers you load chef on them using knife bootsrap, which carefully ensures it installs the revision of chef on the server that you're using on the management workstation. You have to go out of your way to get a brand new release installed on a node if you haven't installed it on your workstation.

one of the recommended ways to install oh-my-zsh

   wget --no-check-certificate https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

Don't forget 'sudo'!

You don't need sudo as this is your user's shell.

I was quite surprised when this was the normal way of installing rvm:

https://rvm.io/rvm/install/

Hence why many use rbenv instead.

https://github.com/sstephenson/rbenv/#neckbeard-configuratio...

https://github.com/sstephenson/rbenv/wiki/Why-rbenv%3F

For me, the method of installation is one of the less important reasons why I started using rbenv instead of rvm. rbenv's simplicity and speed appealed to me, and the trigger for switching was rvm destroying itself again (or otherwise rendering itself unusable) after updating it.

Are you going to type that string into your terminal manually, or are you just copy/pasting that line from a web page, still leaving yourself open to this issue?

I find it hard to believe anyone will be reading that line on a web page, then typing it out correctly in their own terminal instead of just saying, "ok that line looks fine copy paste"

I might copy the command, quickly paste it in my URL bar to make sure it is indeed what I expected, and then paste it into Terminal

I don't understand what this has to do with copying or pasting at all. I would still copy-paste it.

Why would you say that is industry practice when it is not?

It's the suggested install for homebrew. http://mxcl.github.io/homebrew/

There are legit criticisms against the copy-paste-curl-command style of installations. But on the other hand, I've yet to see a critic proposing a viable alternative. With viable I mean that said proposal must:

1. Work on all major platforms.

2. Be easy for the developer to create.

3. Be easy for the user to execute, with as few steps as possible.

There are those who advocate that the developer should create a platform-specific package for every platform. While this fits their purist views in which only their own platform matters, this is not a good solution for the developer, who often has users from multiple platforms. Creating platform-specific packages places an unbelievable maintenance burden on the developer.

This is not to mention that platform-specific packages, too, have their own security flaws.

The only difference between "wget | sh" and "download and run our installer" is that you could inspect the installer before running it. You can still do that, "wget | sh" just simplifies the process for most users.

You can also inspect the wgetted/curl'ed script if you so choose. It's just a URL. I don't understand your point.

Even with the "exploit" in the article, it will be detected as soon as the user pastes the URL in his browser location bar. People who don't inspect what they run are screwed no matter what.

The point, especially in a non-SSL environment, is not that you're not trusting Opscode or Homebrew. It's that a malicious attacker has a vector, because he knows people will be doing something with that URL.

If I own Opscode and I'm smart, I plant something like this on that URL:

    if request.user_agent.startswith("Curl or wget or..."):
        return deliver_malicious_script(request)
    return deliver_everything_is_fine_script(request)

Nearly everybody's workflow for "checking" this is putting the URL in your bar, looking at it, then jumping over to terminal and running it. (Sounds suspiciously like what you just described.) I just owned that with three lines of effort.

We can do this dance all day where people point out specifics, or we can all just recognize it's a bad idea (a lot of people are saying it's a bad idea; might be worth considering it's a bad idea).

The most viable alternative is "apt-get" which provides simple downloads from a central package repository with signature checking. I believe pip and cpan are comparable. In this case I'm picking on homebrew, and the quoted curl command is the command to install that very package tool. The brew package manager does some lightweight checksum verification on subsequent downloads.

And apt-get directly violates point 1, "must work on all major platforms". APT is not widely used on e.g. OS X, Red Hat derivates, etc.

I look forward to you boiling the ocean. (Sadly, the only reason I know about this Homebrew stuff at all is that the APT-based Fink, for MacOS, is not very popular.)

I like very much the "copy-paste-curl-command style of installations" because it is as simple as possible, and it invites to be more creative during installation. I do not envisage to perform a copy-paste-curl-command installation, except perhaps in a not throw away VM. I generally perform the curl toward a temporary file, read the file and if it does look suspicious, I do not run it.

Reply on news.ycombinator.com