curl https://some-url/ | sh

I see this all over the place nowadays, even in communities that, I would think, should be security conscious. How is that safe? What’s stopping the downloaded script from wiping my home directory? If you use this, how can you feel comfortable?

I understand that we have the same problems with the installed application, even if it was downloaded and installed manually. But I feel the bar for making a mistake in a shell script is much lower than in whatever language the main application is written. Don’t we have something better than “sh” for this? Something with less power to do harm?

  • moonpiedumplings@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 days ago

    The non-rolling distros can take a year to update a package, even if they decide to include it.

    There is a reason why they do this. For stable release distros, particularly Debian, they refuse to update packages beyond fixing vulnerabilities as part of a way to ensure that the system changes minimally. This means that for example, if a software depends on a library, it will stay working for the lifecycle of a stable release. Sometimes latest isn’t the greatest.

    Distributions aren’t going to standardize on Arch’s APKBUILD, or Alpine’s almost identical but just slightly different enough to not be compatible PKGBUILD

    You swapped PKBUILD and APKBUILD 🙃

    I’m starting to think something like a yay that installs into $HOME.

    Homebrew, in theory, could do this. But they insist on creating a separate user and installing to that user’s home directory

    • There is a reason why they do this.

      Of course. It also prevents people from getting all improvements that aren’t security. It’s especially bad for software engineers who are developing applications that need on a non-security big fix or new feature. It’s fine if all you need is a box that’s going to run the same version of some software, sitting forgotten in a closet that gets walled in some day. IMO, it’s a crappy system for anything else.

      You swapped PKBUILD and APKBUILD 🙃

      I did! I’ve been trying to update packages in both, recently. The similarities are utterly frustrating, as they’re almost identical; the biggest difference between Alpine and Arch is the package process. If they were the same format - and they’re honestly so close it’s absurd - it’d make packager’s lives easier.

      I may have mentioned I haven’t yet started Void, but I expect it to be similarly frustrating: so very, very similar.

      I’m starting to think something like a yay that installs into $HOME.

      Homebrew, in theory, could do this. But they insist on creating a separate user and installing to that user’s home directory

      Yeah, I got to thinking about this more after I posted, and it’s a horrible idea. It’d guarantee system updates break user installs, and the only way it couldn’t were if system installs knew about user installs and also updated those, which would defeat the whole purpose.

      So you end up back with containers, or AppImages, Snap, or Flatpack. Although, of all of these, AppImages and podman are the most sane, since Snap and Flatpack are designed to manage system-level software, which isn’t much of am issue.

      It all drives me back to the realization that the best solution is statically compiled binaries, as produced by Go, Rust, Zig, Nim, V. I’d include C, but the temptation to dynamically link is so ingrained in C - I rarely see really statically linked C projects.

      • moonpiedumplings@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 day ago

        t’s especially bad for software engineers who are developing applications that need on a non-security big fix or new feature

        This is what they tell themselves. That they need that fix. So then developers get themselves unstable packages — but wait! If they update just one version further, then compatibility will with something broken, and that requires work to fix.

        So what happens is they pin and/or vendor dependencies, and don’t update them, even for security updates. I find this quite concerning. For example, Rustdesk, a popular rust based remote desktop software. Here’s a quick audit of their libraries using cargo-audit:

        [nix-shell:~/vscode/test/rustdesk]$ cargo-audit audit
            Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
              Loaded 742 security advisories (from /home/moonpie/.cargo/advisory-db)
            Updating crates.io index
        warning: couldn't update crates.io index: registry: No such file or directory (os error 2)
            Scanning Cargo.lock for vulnerabilities (825 crate dependencies)
        Crate:     idna
        Version:   0.5.0
        Title:     `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
        Date:      2024-12-09
        ID:        RUSTSEC-2024-0421
        URL:       https://rustsec.org/advisories/RUSTSEC-2024-0421
        
        Crate:     libgit2-sys
        Version:   0.14.2+1.5.1
        Title:     Memory corruption, denial of service, and arbitrary code execution in libgit2
        Date:      2024-02-06
        ID:        RUSTSEC-2024-0013
        URL:       https://rustsec.org/advisories/RUSTSEC-2024-0013
        Severity:  8.6 (high)
        Solution:  Upgrade to >=0.16.2
        
        Crate:     openssl
        Version:   0.10.68
        Title:     ssl::select_next_proto use after free
        Date:      2025-02-02
        ID:        RUSTSEC-2025-0004
        URL:       https://rustsec.org/advisories/RUSTSEC-2025-0004
        Solution:  Upgrade to >=0.10.70
        
        Crate:     protobuf
        Version:   3.5.0
        Title:     Crash due to uncontrolled recursion in protobuf crate
        Date:      2024-12-12
        ID:        RUSTSEC-2024-0437
        URL:       https://rustsec.org/advisories/RUSTSEC-2024-0437
        Solution:  Upgrade to >=3.7.2
        
        Crate:     ring
        Version:   0.17.8
        Title:     Some AES functions may panic when overflow checking is enabled.
        Date:      2025-03-06
        ID:        RUSTSEC-2025-0009
        URL:       https://rustsec.org/advisories/RUSTSEC-2025-0009
        Solution:  Upgrade to >=0.17.12
        
        Crate:     time
        Version:   0.1.45
        Title:     Potential segfault in the time crate
        Date:      2020-11-18
        ID:        RUSTSEC-2020-0071
        URL:       https://rustsec.org/advisories/RUSTSEC-2020-0071
        Severity:  6.2 (medium)
        Solution:  Upgrade to >=0.2.23
        
        Crate:     atk
        Version:   0.18.0
        Warning:   unmaintained
        Title:     gtk-rs GTK3 bindings - no longer maintained
        Date:      2024-03-04
        ID:        RUSTSEC-2024-0413
        URL:       https://rustsec.org/advisories/RUSTSEC-2024-0413
        
        
        Crate:     atk-sys
        Version:   0.18.0
        Warning:   unmaintained
        Title:     gtk-rs GTK3 bindings - no longer maintained
        Date:      2024-03-04
        ID:        RUSTSEC-2024-0416
        URL:       https://rustsec.org/advisories/RUSTSEC-2024-0416
        
        

        I also checked rustscan and found similar issues.

        I’ve pruned the dependency tree and some other unmaintained package issues, but some of these CVE’s are bad. Stuff like this is why I don’t trust developers to make packages, they get lazy and sloppy at the cost of security. On the other hand, stable release distributions inflict security upgrades on everybody, which is good.

        Yeah, I got to thinking about this more after I posted, and it’s a horrible idea. It’d guarantee system updates break user installs, and the only way it couldn’t were if system installs knew about user installs and also

        ???. This is very incorrect. I don’t know where to start. If a package manager manages it’s own dependencies/libraries, like nix portable installs, or is a static binary (e.g: soar), then system installs will not interfere with the “user” package manager at all. You could also use something like launchd (mac) or systemd users services (linux) to update these packages with user level privileges, in the user’s home directory.

        Also, I don’t know where you got the idea that flatpaks manage “system level” software.

        It all drives me back to the realization that the best solution is statically compiled binaries, as produced by Go, Rust, Zig, Nim, V.

        I dislike these because they commonly also come with version pinning and vendoring dependencies. But you should check out Soar and it’s repository. It also packages appimages, and “flatimages”, which seem to be similar to flatpaks but closer to appimages in distribution.