Hacker News new | ask | show | jobs
by colemannugent 3075 days ago
Cool, now I don't need to remember the arcane incantation to download a file with Powershell.

Do you think we'll see things like the good old "curl <some url> | bash" for Windows now? They still have no package manager worth using.

9 comments

Windows 10 has a "package manager", of course, that's quite good, but both user culture, developer disinterest, and years and years of inertia keeps it from being used for enough things to cross the network-effect side of some treshold of "worthwhile".

The 'download | execute' paradigm, on the other hand, is the complete antithesis of package management, to where your desire to obtain and execute the code trumps your willingness and patience to wait until it has been vetted by your preferred package manager, and installed in a less haphazard way. I fail to see your point.

If you are referring to the package management stuff in PowerShell, that's just a unified interface to several different package management systems, each of which handles specific types of packages. Windows has MSI, VSIX, PowerShell modules and probably some others as well, all of which are separate from Microsoft Update.
> curl <some url> | bash

That's still not a package manager worth using.

Have you tried chocolatey? I’ve really enjoyed using it
MSYS2 now comes with pacman! it's great.
Hasn't that been popular as iwr <some url> | iex for a while?
scoop(1) is a pretty cool package manager

1) https://github.com/lukesampson/scoop

> the good old "curl <some url> | bash"

I would be thankful if the habit of trusting a random IP with control of one's shell could die, forever.

Why would you be using a random ip? That incantation is usually used with a URL where you would have just downloaded and installed the software manually anyway.

There are various arguments against the curl-piped-to-shell idiom but "random ip" doesn't seem like a valid one.

A URL and an IP are not equal.

Building a script that acts differently for a web browser, a normal download, and curl, is trivial, and I've seen it happen. Here's a proof-of-concept[0] someone else wrote.

Manually downloading is safer, at least you can review, curling straight into a shell is inherently unsafe.

The better option is still a package manager, but curling straight to a shell is very unsafe.

[0] https://jordaneldredge.com/blog/one-way-curl-pipe-sh-install...

Why would you be using an IP and not a URL?

And why wouldn't you trust the source of the install script as much as any other installer?

Do you audit the binary installers you use as well?

I don't disagree about a minor difference between the methods, but I definitely disagree with piping to sh being "very unsafe". If you trust the site/author enough to run their code on your computer at all, the install method risk difference is but a tiny drop in the bucket.

> If you trust the site/author enough to run their code on your computer at all

Piping curl, means you can't be sure it came from the author's site.

It means you can't be sure you're getting the same software you've been considering installing.

It means a broken connection is a broken install, with no cleanup and no idea what it has changed.

> Do you audit the binary installers you use as well?

Don't install random binaries either. The security implications of that should be fairly obvious.

> Piping curl, means you can't be sure it came from the author's site.

Up to the trustworthiness of the CA system yes you can. If the author's site is serving malicious downloads to the curl UA then you're probably hosed either way. It would be easier to just slip malicious code in the software itself.

> It means a broken connection is a broken install, with no cleanup and no idea what it has changed.

This is the real draw of package management. The argument surrounding curl|bash should really focus on this rather than hand-wavy security.

> Don't install random binaries either

Nobody who is running curl|bash isn't installing a 'random' binary but downloading an installer from a source they trust.

You didn't answer the 'random ip' question.

> Piping curl, means you can't be sure it came from the author's site.

Assuming you take the same precautions you'd take with any other software download (like using https), there's no difference between curl-piped-to-sh and clicking on a link to a rpm, deb, exe, or anything else.

> It means a broken connection is a broken install

Not if the shell script is written correctly. And if you can't trust the source of your software to get that right, then you can't trust them to get the regular installers right either, so there's no difference here either.

> Don't install random binaries either

No one's advocating for random binaries, but you do have to install binaries from time to time, no? Or are you getting your CPU microcode updates in source form too?

I get it, it's a knee-jerk cargo-cult reaction to flame folks who don't see the huge issue with piping a https URL from the software's main web site to the shell, but if you actually think about it, it does not have the major flaws that you claim it does.

Precisely. Why would anyone do that is beyond me.
If you're still using Windows PowerShell proper instead of PowerShell Core, you still need to delete the curl alias or call curl explicitly as curl.exe in order to use it.

Also, take a look at Chocolatey for package management. Yeah it's not a built-in thing, but it's pretty decent.

I hated Chocolatey. Those binary shims seemed to produce slow, unstable binaries. There also still isn't a fully-usable Chocolatey backend for the PowerShell package manager.

The Programs & Features pane works just fine for me as a package manager.

Yeah, “iwr” sure was hard to remember.
I'm pretty sure curl is also an alias for iwr.
Curl some url and execute is a massive security risk.
In what way is it more of a risk over downloading and executing an installer from the same site?

The only reason I can think of is if the script partially downloads and only half executes. Doesn't seem "massive" though...

As opposed to download in IE and then double click the executable? At least on Windows that battle has already been lost.