Hacker News Reader

Comment by raesene4 | Hacker News Reader

The thing I don't see in this article, which I do regard as (another) drawback to curl|bash is that you're not just trusting the software developer, you're also trusting their hosting provider.

Anyone who gets access to modify that script on their server can change the content.

Now it could be that they're hosting on a dedicated system, in a datacentre that they own, with no 3rd party access, but that's very much not the norm for most companies these days, and it's impossible for a customer to verify.

This is a problem which is solved with good package signing practices, where the developer signs the content on a system they control before distribution, so at least you can verify that what you're installing is what they released.

View on HN

How is that an argument against curl|bash? If you download a source tarball from the developer's website, then you are also trusting their hosting provider. curl|bash changes nothing.

A source tarball can (and should!) be checked against GPG signatures et. al.

With curl|bash you have nothing.

A bash script can be signed too. See article.

How many projects provide GPG signatures for their tarballs?

How often do you check signatures on tarballs?

> How often do you check signatures?

Every time you run apt-get. So the answer is almost every time.

The context of the comment is source tarballs. How often do you check the signatures on random tar.gz you download?

tar.gz vs. curl|bash is a false dichotomy, there is no reason for either. We have better ways to install software these days.

And yes, when I download tar.gz (e.g. when I am responsible of managing my own packages) I do check the signatures. You should, too.

Could you point me to the better way of installing software that will work on all Linux distros?

District-appropriate packages.

Use the right fucking tool for the job.

That will not work on all Linux distros. That is writing a specific installer for each distro, which does not satisfy my requirements and as such is not the right tool for the job.

> That will not work on all Linux distros

The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer.

> That is writing a specific installer

What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where.

> The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer.

Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere.

> What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where.

You will probably write a script to build your package, right? That's writing an installer. Or a builder for an installer, or however you want to call it. The point is that you now have to do work for every distro you want to support, and all users without a package manager that you support is SOL.

> Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere.

Unless the user has existing files with the same names there. Or they edit a config file you placed in /etc/ and then they run the installer for a new version. Oh so now your "simple" installer has to handle version upgrades, and file conflicts?

If your software is literally so simple as files in /usr/bin and /etc, building packages to install those files should be easier than writing a good install script, because the package manager will handle so many use-cases for you out of the box.

> You will probably write a script to build your package, right?

No? I have a makefile which can do the actual building and installing. dh_make will generate a debian directory, and debuild will call this makefile. An RPM specfile also will have calls to make build, make install, etc.

None of this is writing an installer unless you consider a makefile having an "install" target "writing an installer".

> The point is that you now have to do work for every distro you want to support If the installation is as simple as you claim, the packages will be simple wrappers around the results of a makefile.

If its more complex, then packages are still easier to maintain, because you don't need to worry about "what distro am i on, and do i need to check what the apache binary is called, or what packages are installed by default".

> and all users without a package manager that you support is SOL.

If I haven't covered some Distro, it's hardly difficult to give them a .tar.gz containing the tree created by the aforementioned `make install`. This is still less work than your special installer script.

> Unless the user has existing files with the same names there. Or they edit a config file you placed in /etc/ and then they run the installer for a new version. Oh so now your "simple" installer has to handle version upgrades, and file conflicts?

And these scenarios would make deb's and rpm's bail out as well.

> No? I have a makefile which can do the actual building and installing. dh_make will generate a debian directory, and debuild will call this makefile. An RPM specfile also will have calls to make build, make install, etc.

A makefile is a script. An RPM specfile is also a script.

> If I haven't covered some Distro, it's hardly difficult to give them a .tar.gz containing the tree created by the aforementioned `make install`. This is still less work than your special installer script.

People will also be much less likely to actually install your software this way.

> And these scenarios would make deb's and rpm's bail out as well.

Conflicting config files can be handled intelligently by deb and rpm based package managers.

Does your install script identify whether or not the user made any changes to the config file your previous installer script placed in /etc 9 months ago, and give them options (including viewing a diff and an interactive shell while installation is paused) about how to handle it if they did make changes, and use the new one if they just used the default? I doubt it somehow.

> A makefile is a script

How do you build the binaries that your special install script installs then? My point is that package building tools generally leverage an existing makefile that you would already have.

> People will also be much less likely to actually install your software this way.

Given that my software targets Linux servers, I actually imagine they're more likely to install from my packages (or an archive on a weird unsupported distro) than from your home-grown install script.

> Does your install script identify whether or not the user made any changes to the config file your previous installer script placed in /etc 9 months ago, and give them options (including viewing a diff and an interactive shell while installation is paused) about how to handle it if they did make changes, and use the new one if they just used the default? I doubt it somehow.

It doesn't overwrite anything because the file is intended to be modified. Problem solved.

> How do you build the binaries that your special install script installs then? My point is that package building tools generally leverage an existing makefile that you would already have.

I don't write C, I usually write python (interpreter already installed), Go (static binary) or sh (interpreter already installed). These never use makefiles, so I'd have to script a new one for this. And then there's dealing with all the different tools to generate the different kind of packages.

> Given that my software targets Linux servers, I actually imagine they're more likely to install from my packages (or an archive on a weird unsupported distro) than from your home-grown install script.

I was comparing the install script with providing a .tar.gz file with some files in it. Obviously people would prefer for packages for their obscure system, but alas, they don't exist.

LSB-compliant RPMS, though there are a few aggressively antisocial distributions that don't support them as well as they should.

I just want to add my agreement to this. If the LSB (Linux Standard Base) was better supported these hacks would not be necessary.

AppFS :-)

This is why signatures should be embedded into the packaging and distribution mechanism, to reduce manual steps.

Looking at Dockers deployment of Content Trust as an example of this.

You still have a trust decision on first use, but it's better protection than nothing.

> You still have a trust decision on first use, but it's better protection than nothing.

That's what you're getting by curl|bashing sandstorm today (if you skip the PGP verification step). Once installed the updater verifies signatures automatically.

I was referring to cryptographic package signing (e.g. with PGP) so you validate the signature of the package before installing, this lets you validate that the package hasn't been modified since it was signed.

curl|bash ing a script does not provide this protection.

Why do you trust that the signing key actually belongs to the developer? If I were an evil hosting provider I would simply change the key fingerprint displayed on the download page.

You have ways of veryfing the ownership of a key: PGP's web of trust or keybase.io for examples.

Also, assuming you keep the key, it prevents someone from attacking you through this channel in the future. Instead of trusting the distribution channel every time, you just have to trust it once. Not perfect, but surely an improvement. Similar to the SSH security model.

Personally I verify keys to the best of my ability on first install, and then only use that key to verify in the future.

Of course you can still check signatures if you wish. Heck, sandstorm even provides instructions on how to do it on their installation manual: https://docs.sandstorm.io/en/latest/install/#option-3-pgp-ve...

But curl|bash is a one step process, as soon as you get the script you execute it, with no opportunity to check a signature...

You do realize you don't have to use curl|bash, right? You can wget, verify with gpg and then bash it.

Of course, but then we're not talking about curl|bash anymore. It seems kind of contradictory to say that curl|bash is secure as long as one doesn't actually curl|bash.

I feel like curl|bash is for the masses, who don't care. Then there are more secure options for those who do care.

I think that once we're talking about installing server software at the command line, we're already beyond most of the masses.

I'd also argue that secure defaults are most important for folks who don't care. And there are more secure options: the package managers.

Don't forget about workstations, but you're right. Though personally I install a lot of stuff on one-off VMs to try it out. I don't really care about security there because the VM is in an isolated network and will be erased an hour later anyway.

> And there are more secure options: the package managers.

So sandstorms installation guide should in your opinion just say "wait a couple of years and maybe someone will have packaged it for your distro"? Yes, that sounds excellent way of getting users. And hey, the most secure way of installing software is not to!

you can host your own repos pretty easily, and still provide the bash script for oddball distros.

I don't think it's possible to make things secure for people who don't care, except by disallowing third-party software entirely. Deciding who you trust is fundamental.

curl|bash is just a shorthand way to say "here is an URL for install script you can run with bash" which happens to be also conveniently copy-pasteable. You can do whatever you want with that information.

Of course, but the article being discussed is about curl|bash so I felt that comment was relevant :)

Reply on news.ycombinator.com