|
|
|
|
|
|
by tenken
4376 days ago
|
|
|
with "curl -s" at least, curl wont send anything onto the next process until it's done receiving (all) the data. _If_ the pipe breaks up the incoming data, I assume its on 1 of these boundaries of 64kb-ish:
http://unix.stackexchange.com/questions/11946/how-big-is-the... http://stackoverflow.com/questions/4624071/pipe-buffer-size-... In general, when I've seen this technique used in Ruby (RVM?, back in the day) and/or PHP (Composer recommends a similiar Curl install technique, but composer.phar is an digest-archive of sorts ....) the installer code tends to be about a paragraph worth of text. All in all I understand your point. But your contrived example of rm -rf seems a little too contrived. In this case we're were talking about PHP code ... the chunked-piped code would still need to be valid PHP of what "rm -rf /" is not as it's missing important tokens to denote valid php expression(s). It seems like it would be equally worrisome to worry about Brownian Motion flipping a bit in memory and catastrophically affecting my program execution -- possible but unlikely. |
|
|
There are several scenarios where that logical pipe can fail. It doesn't have to happen cleanly on a 64-kb unix pipe buffer boundary. Some examples may include someone bouncing an office router and all TCP connection states getting reset, a neighbor microwaving lunch and WiFi radios croaking, a carrier having networking issues and connections timing out, the remote server restarting the web server after a software upgrade, etc..
I'm not sure curl (even with -s) will gracefully handle all of these cases defensively (doubly-so if the HTTP server was sending back chunked-encoding without explicitly specifying a Content-Length)
(anecdotally, since you mentioned flipping bits, it's possible but unlikely until you have to deal with it - http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-so... )
At the end of the day, having not even considered what an active attacker could do but just what could naturally blow-up a small percentage of the time I'm inclined to say "that's bad, mmkay?" and try to persuade developers not to push that as a safe installation method. Even if they've triple-checked that the code they've written + interpreter can not possibly do harm in that case, the signal we should be sending (primarily to end-users) is that this may be an unsafe operation.