Thread

1. deadbunny · 1791120801 · focus · HN ↗

   &gt; Set up Strata on this PC for me: <a href="https:&#x2F;&#x2F;github.com&#x2F;Niko1221&#x2F;Strata" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Niko1221&#x2F;Strata - follow docs&#x2F;AI_SETUP.md in that repository.

   And I thought piping to bash was bad

   1. Skunkleton · 1791126347 · focus · HN ↗

      I&#x27;ve never understood the security argument people are making when they complain about `curl foo | bash`. I get that these scripts sometimes mess up your bashrc or whatever, but from a security perspective I see no issue. You are already installing software from the same domain. If they were going to do something nasty, they could do it with any of the software you are using from them. It doesn&#x27;t have to be the setup script.

      1. minitech · 1791128945 · focus · HN ↗

         To compare it to just one other option: when you run `npx foo`, you know* that you’re getting the same public artifact that anyone else running it at the same time would get. (If you have a `min-release-age` configured, you also benefit from that.) If I wanted to distribute software like this, I’d include npm-shrinkwrap.json; then, with `npx foo@1.2.3`, you could be similarly confident in getting the same app every time.

         (I picked this option for ease of comparison, getting a couple of major security wins with very low effort; I don’t recommend `npx`ing stuff in an otherwise unprotected environment either.)

         * well, you can be somewhat more sure

         1. athrowaway3z · 1791130561 · focus · HN ↗

            So to be clear; the solution is then something like

            `curl <a href="https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;my&#x2F;domain&#x2F;setup.sh" rel="nofollow">https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;my&#x2F;domain&#x2F;setup.sh | sh`

            Note we dont even have a hash there - just a promise that a third party (github) has a log of whatever was hosted at that url.

            1. nagaiaida · 1791135554 · focus · HN ↗

               maybe then we&#x27;ll pin hashes instead of filenames, and oops now anybody can fork my&#x2F;domain and hand out a link that looks official with whatever contents they wish
         2. slowin · 1791133210 · focus · HN ↗

            While I don&#x27;t think piping curl into bash is the most secure, npm installing has proven time and time again to open yourself up to supply chain attacks. At least with curl you know that you&#x27;re getting the supply chain put together by the software author. With npm, every single library is a vector for attack every time you update.

            1. minitech · 1791133552 · focus · HN ↗

               You’d be getting the supply chain put together by the software author in either case. It’s common to do both badly, but if you care about doing it well, that’s easier with npm (e.g. shrinkwrap, as mentioned) and can be taken farther (the non-varying artifact thing).

               1. slowin · 1791135641 · focus · HN ↗

                  Npm dependencies resolve at install time though, so some of the pinned versions may have changed ownership or otherwise been modified since the author pinned them. With the curl | bash solution you&#x27;re getting a singular supply chain packaged by the author at release time.

                  1. cpuguy83 · 1791138333 · focus · HN ↗

                     With curl|bash you are literally getting anything that happens to be in that script. These are frequently poorly constructed, so not check hashes or pin dependencies they install. Even security companies (see trivy supply chain attack) get these badly wrong.

                     I&#x27;m not replying here to say one is better than than the other (npm has obviously had its share of problems) but rather to combat claims that curl|bash is somehow safer, it absolutely is not, in fact it&#x27;s all the bad stuff about npm without the pretense of being potentially safe.

Unofficial Hacker News client; not affiliated with Y Combinator.