Hacker News Reader

Comment by dekz | Hacker News Reader

    DownloadString("http://bit.ly/psChocInstall"))

I don't think that is the best idea ever had...

View on HN

I understand your specific security concerns, but the whole line is offensive. Certainly not the fault of the Chocolatey authors, but this is what I'd call a massively over-engineered shell:

  iex ((new-object net.webclient).DownloadString("http://bit.ly/psChocInstall"))

Good thing we have bash: a paragon of both simplicity and readability!

Not sure if sarcasm or zealotry.

Except for the "iex" this isn't really Powershell specific - it's just instantiating a .NET framework object and calling a method on it. It might as well be C#.

No it might as well not be. One of the big complaints about powershell is how unclear the command line syntax for tools tends to be. A big part of developing a good C# API (or any for that matter) is clarity, readability and understanding. One of the reason fluent APIs are popular. Bad is bad, don't blame .NET or C# for that.

And yeah I realize you can come up with an ugly command line example in just about anything. But powershell tends to be one of the uglier ones out there.

We started with a much more involved set of steps to install and people kept wanting a one liner for the install. It's a tradeoff

Huh? It's calling DownloadString on a System.Net.WebClient. That IS a C# API. I'm not sure what you're talking about.

That being different from using wget or curl in bash or easy_install how again?

  wget http://bit.ly/psChocInstall

  ((new-object net.webclient).DownloadString("http://bit.ly/psChocInstall"))

If you happen to have wget, sure. Windows doesn't, by default. It is far more likely that the machine will have powershell, and if it does, it has the .net frameworks.

But, with wget, the line is

  iex (wget -qO- http://bit.ly/psChocInstall)

which isn't too bad.

That is just a way to install chocolatey. After you install, running installs is 'cinst somepackagename'

Why not? There's plenty of things that are installable that way. For example:

RVM:

    bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )

Homebrew:

    /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

Because you are installing programs on your computer from a "shortened URL", which could point anywhere. Your examples use a URL that is the final destination so you can make an informed decision whether you are willing to trust that URL.

If you use the "append a +" bit.ly feature, you can check where it ends up, but not everybody knows to do that. https://bitly.com/psChocInstall+

A non-shortened URL can point anywhere as well. The only way to "make an informed decision" is to put the URL in your browser—that goes for shortened and non-shortened URLs.

If I were to attack someone with such a scheme, I would take care of serving clean files to a web browser (say, with the user-agent string) and the infected files to command-line invocations. :)

Yes, that's quite a security risk, but it also affects shortened and non-shortened URLs equally.

With a non-shortened URL you have one attack vector, hack the website. With a shortened URL you have two attack vectors, hack the website or hijack the shortened URL to point to your own server.

Would providing the full link be a better idea? For the installer experience, people wanted short and memorable.

1) Those links from github are served over https, lets ignore the fact that curl might ignore it though.

2) .com isn't as potentially susceptible as a Libyan tld.

3) They are relying on bit.ly to serve the correct file.

Perhaps the full url to the github file would reduce the cryptic url?

IIRC, a few months ago there was quite a large discussion here on HNs about the reason you shouldn't do either of those.

Can't find the discussion, but there is certainly a fairly large body of people who oppose those examples as well.

Reply on news.ycombinator.com