Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Very nifty, but I'd argue against it due to possible confusion in various atypical scenarios, such as:

* The user wants to read the script before executing it, and their preferred reader (perhaps due to browser extension or something) is a standard browser.

* The user has `curl` aliased to `curl-impersonate` in order to avoid things like Cloudflare's bot detection (a captcha that triggers on things beyond the HTTP request, like the less fancy TLS handshake of regular curl) -- https://github.com/lwthiker/curl-impersonate

* The user doesn't have curl installed, but has wget / lynx / some headless browser / etc. and expects any of those to work the same as curl.

Not to mention, if a site encouraged users to execute an HTTP response by piping curl into sh, and the response for curl was different than the response otherwise, that just might make the top of HN for being sketchy as hell.



> The user wants to read the script before executing it, and their preferred reader (perhaps due to browser extension or something) is a standard browser.

I mean, the point of wanting to read the script before executing it is to try and protect yourself from malicious scripts that abuse the curl | sh pattern. So since it would be simple enough for a malicious actor to return something different when the user agent indicates the usage of curl, the only responsible thing to do, anyway, is to use curl to download the script to a file, read the file, then execute the file.

> `curl` aliased to `curl-impersonate`

So when the user uses a tool to impersonate a browser, they'll see exactly what they'll see in a browser... which are the quick-install instructions anyway, which can include a note about the user agent, if anyone actually hits this in the real world?

> wget / lynx / some headless browser

Which would provide the quick-install instructions to use curl :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: