13 comments

[ 3.1 ms ] story [ 42.8 ms ] thread
Is this a joke? It's still running "curl | bash", just in a script instead of on the command line.
I think it's a joke. It's hard to tell (Poe's law), but I'm not sure why it's getting upvoted so fast.

Edit: OTOH this project by the same author is much cooler: https://github.com/kovetskiy/spin

I can't help but think that that executable could have been much smaller, like < 50 lines, in Haskell. First stab at it, with less-rich command-line arguments:

    import Prelude hiding (getContents)
    import Control.Exception
    import Control.Concurrent
    import System.Environment -- for getArgs
    import Data.ByteString (getContents) -- for strictness
    import System.IO hiding (getContents)

    spin :: String -> Handle -> IO ()
    spin s h = sequence_ $ cycle [p " \\", d, p " -", d, p " /", d] where
        p c = hPutStr h ('\r' :  s ++ c) >> hFlush h
        d = threadDelay 100000

    main = do
        prompt <- getArgs
        let actualPrompt = if null prompt then "Loading" else head prompt
        sThread <- forkIO (spin actualPrompt stdout)
        getContents
        throwTo sThread ThreadKilled
I mean there are some serious problems with the above, like that I can't guarantee that Haskell will see the `ByteString.getContents` by itself on one line and use constant memory knowing that the resulting bytestring will not be used... maybe I need something more like `catchIOError (sequence_ $ repeat getChar) (\e -> if IO.isEOFError e then return () else ioError e)` to consume the stream with fixed overhead without blocking... but it seems like argument-handling, printing out usage information, and getting O(1) memory usage can't possibly quintuple this thing's length.
The best alternative to running `curl | bash` is still... `curl | bash`. Please tell me this is missing a commit.
I was expecting this to be an attempt at fixing the security issues of curl | bash.

I was disappointed

One of the biggest complaints about the curl - bash paradigm are the security implications. URLs can point to different content at different times. Project maintainers can (and have) changed the content at these URLs for malicious or other reasons. A lot of people will not examine the source of what they're piping into the shell.

To me, https://github.com/jbenet/hashpipe addresses a lot of these issues by pinning the content to a hash.

You can't force somebody to read and understand the install script, but at least those who do can know it's the one they verified in advance.

Kubernetes uses this way, so why not?
Because it's lazy and insecure?
Unix rule: if there isn't an error, don't display anything..

Those "installing xx" would be useless..

(comment deleted)