Most active commenters
  • shakna(5)
  • saagarjha(3)

←back to thread

Java Hello World, LLVM Edition

(www.javaadvent.com)
200 points ingve | 12 comments | 07 Dec 25 11:51 UTC | HN request time: 0.39s | source | bottom
Show context
tuhgdetzhh ◴[07 Dec 25 15:13 UTC] No.46182258[source]▶
I'm always a bit shocked how casual people people wget and execute shell scripts as part of their install process.

This is the equivalent of giving an author of a website remote code execution (RCE) on your computer.

I get the idea that you can download the script first and carefully read it, but I think that 99% of people won't.

replies(5): >>46182378 #>>46182490 #>>46183270 #>>46184246 #>>46184808 #
1. stouset ◴[07 Dec 25 20:24 UTC] No.46184808[source]▶
I’m always a bit shocked how seriously people take concerns over the install script for a binary executable they’re already intending to trust.
replies(2): >>46185279 #>>46186741 #
2. romaniitedomum ◴[07 Dec 25 21:22 UTC] No.46185279[source]▶
> I’m always a bit shocked how seriously people take concerns over the install script for a binary executable they’re already intending to trust.

The issue is provenance. Where is the script getting the binary from? Who built that binary? How do we know that binary wasn't tampered with? I'll lay odds the install script isn't doing any kind of GPG/PGP signature check. It's probably not even doing a checksum check.

I'm prepared to trust an executable built by certain organisations and persons, provided I can trace a chain of trust from what I get back to them.

replies(1): >>46186706 #
3. ◴[07 Dec 25 23:57 UTC] No.46186706[source]▶
4. shakna ◴[08 Dec 25 00:01 UTC] No.46186741[source]▶
Between you and me, are a bunch of other hops. Blindly trusting dependencies is one part of why npm is burning down at the moment.

Why trust un-signatured files hosted on a single source of truth? It isn't the 90s anymore.

replies(2): >>46188405 #>>46208400 #
5. saagarjha ◴[08 Dec 25 04:40 UTC] No.46188405[source]▶
What’s your alternative?
replies(1): >>46189112 #
6. shakna ◴[08 Dec 25 06:34 UTC] No.46189112{3}[source]▶
A mirrored package manager, where signature and executable are always grabbed from different sources.

Like apt, dnf, and others.

replies(1): >>46189844 #
7. saagarjha ◴[08 Dec 25 08:36 UTC] No.46189844{4}[source]▶
Pretty sure my apt sources have the signing and package pointing to the same place
replies(1): >>46189948 #
8. shakna ◴[08 Dec 25 08:50 UTC] No.46189948{5}[source]▶
If you have more than a single source, then apt will already be checking this for you.

The default is more than a single source.

replies(1): >>46190634 #
9. saagarjha ◴[08 Dec 25 10:21 UTC] No.46190634{6}[source]▶
All of mine point to like somethingsomething.ubuntu.com
replies(1): >>46191076 #
10. shakna ◴[08 Dec 25 11:29 UTC] No.46191076{7}[source]▶
If it points to mirror.ubuntu.com, it'll be mirroring at host end, instead of inside apt. But as apt does do resolution to a list, it'll be fetching from multiple places at once.
11. stouset ◴[09 Dec 25 18:16 UTC] No.46208400[source]▶

    $ curl ${flags} https://site.io/install.sh | sh

    $ curl ${flags} https://site.io/tool > ./tool
    $ chmod u+x ./tool
    $ ./tool
Both of these are effectively the same damn thing but everyone loses their minds over the first one.

Also, a lot of those install scripts do check signatures of the binaries they host. And if you’re concerned that someone could have owned the webserver it’s hosted on, then they can just as easily replace the public key used for verification in the written instructions on the website.

replies(1): >>46209345 #
12. shakna ◴[09 Dec 25 19:24 UTC] No.46209345{3}[source]▶
I'm not advocating for either of those.

    pacman -Sy {tool}
    pkg_add {tool}
    apt install {tool}
Even the AUR does a lot more to make you secure, than a straight curl - even though throwing things up there is easy.