[HN Gopher] Vet is a safety net for the curl | bash pattern
___________________________________________________________________
Vet is a safety net for the curl | bash pattern
Author : mooreds
Score : 164 points
Date : 2025-07-24 12:47 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| chromehearts wrote:
| https://pi-hole.net/blog/2016/07/25/curling-and-piping-to-ba...
|
| A good read
| Kinrany wrote:
| What does it do about the curl|bash itself downloading software
| at runtime?
| krunck wrote:
| That's why you need to inspect the script.
| stouset wrote:
| And if I--an evildoer--leave the script alone and simply
| replace the installed binaries with compromised ones?
| devmor wrote:
| I like this. Convincing people not to pipe remote scripts to
| their shell seems like a lost battle, so making it safer to do is
| a very good mitigation strategy.
| superkuh wrote:
| Indeed. curl | sh is literally the #1 recommended and most
| common way to install the rust development toolchain (because
| it changes too rapidly to effectively be in any repos). It's
| crazy that a language that prioritizes security so highly in
| it's design itself is only compiled through such insecure
| methods.
|
| Ref: https://www.rust-lang.org/tools/install
| >Using rustup (Recommended) >It looks like you're
| running macOS, Linux, or another Unix-like OS. To download
| Rustup and install Rust, run the following in your terminal,
| then follow the on-screen instructions. See "Other Installation
| Methods" if you are on Windows. >curl --proto
| '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
| goku12 wrote:
| That's a misunderstanding. You can completely avoid the curl
| bash pattern if you can install the rustup binary and setup
| the relevant environment variables (like PATH) manually.
| Everything else, including cargo and various toolchain
| versions are installed and managed by rustup. And rustup
| doesn't have as much churn as the rest of the tools. So,
| rustup can be (and is) packaged for many distributions.
| That's all that's necessary in practice. They recommend curl
| bash because it automates all the above in a single script
| without exposing such lengthy explanations to a beginner.
| superkuh wrote:
| >You can completely avoid the curl bash pattern if you can
| install the rustup binary and setup the relevant
| environment variables (like PATH) manually.
|
| Are you saying that if you avoid the curl bash pattern then
| you can avoid the curl bash pattern? This is true, and
| trivial, and completely irrelevant to what the rust website
| recommends and what most people do.
|
| There's definitely been a misunderstanding. The
| misunderstanding is that you think people are installing
| rust from rustup from their repos. The website shows you
| this is not the most common case.
|
| I do get your point that it doesn't have to be this way
| anymore. That rustup itself _could_ be in repos and still
| work (even rustc /etc can't). But this is not not how it
| has been done for rust's entire existence and change is
| slow and hard. Is there a single distro that does do this
| _now_?
| kibwen wrote:
| _> That rustup itself could be in repos and still work_
|
| So surely you acknowledge that rustup not being in any
| given distro's repo isn't something that the Rust
| developers have control over? How do you expect the Rust
| devs to distribute the compiler? If you want to build
| from source, that's extremely easy. For people who want
| convenient binaries, Rust also offers binaries via the
| most convenient means available, which is curl-to-bash.
| This isn't a security flaw any more than running the
| compiler itself is.
| veber-alex wrote:
| rustup is available on plenty of distros now, and it's on
| homebrew in macOS.
|
| The Rust docs should really offer installation methods
| other than curl | sh. Not from a security standpoint (I
| think that's nonsense) but I just don't like polluting my
| system with random stuff that is not managed by a package
| manager.
|
| Edit: Yes, there is an "other installation methods" link,
| but the text makes it sound like it is only applicable
| for Windows.
| shadowgovt wrote:
| This is probably the key idea in this specific context:
| the tool you're downloading is a compiler. If you don't
| trust the bash script hosted by the compiler's creators
| (assuming you're properly certificate-checking the curl
| connection and not bypassing TLS), why would you trust
| the compiler binary it's trying to install?
| superkuh wrote:
| I trust Debian to vet and package things in a way that
| won't break my desktop. I don't trust the Rust
| organization because their goals are very different.
| shadowgovt wrote:
| I'm not sure how that's relevant for rust. I'm trying to
| think of a way they _could_ distribute the rust toolchain
| that would break your desktop; does your desktop have a
| native rust install that other pieces of the distro are
| relying on to have a particular configuration (like the
| gcc most distros ship with) that a curl | bash installed
| toolchain would interfere with?
| mustache_kimono wrote:
| > I trust Debian to vet and package things in a way that
| won't break my desktop.
|
| Um, has there been some instance where rustup broke a
| desktop? And I'm assuming Debian has actually delivered
| on this worst case scenario?
| shadowgovt wrote:
| Debian's done a pretty good job here. If you run unstable
| you'll get up to Rust 1.85 (whereas the project home will
| get you 1.88).
|
| Of course, it's Debian; _stable_ is alllll the way back
| on 1.63, state of the art in 2022.
| mustache_kimono wrote:
| > Debian's done a pretty good job here.
|
| I meant I bet Debian has broke desktops with a simple
| `apt update`. Whereas show me where rustup has broken a
| desktop?
| superkuh wrote:
| >you acknowledge that rustup not being in any given
| distro's repo isn't something that the Rust developers
| have control over
|
| The lack is a consequence of the type of language rust
| developers chose to be. One that is constantly, rapidly
| (over just a few months) changing itself in forwards
| incompatible ways. Other languages don't really have this
| problem. Even c++ you only have breaking changes every
| 3-4 years which can be handled by repos. But 3 months old
| rustc in $distro repos is already fairly useless. Not
| because rust is a bad language, but because the types of
| people that write in rust are all bleeding edge early
| adopters and always use $latest when writing. In another
| decade or so when the rust developer demographics even
| out a bit it will probably be okay.
| pixelesque wrote:
| What exactly are you arguing?
|
| The Parent poster is arguing that the "recommended" way
| documented on the Rust website to install rustup is using
| curl bash, and you're saying "it's possible to do things
| manually".
|
| How is that helpful to the vast majority of the people on
| Mac/Linux trying to install Rust from scratch and reading
| the instructions on the website?
| navels wrote:
| same parent had said "It's crazy that a language that
| prioritizes security so highly in it's design itself is
| only compiled through such insecure methods."
| kibwen wrote:
| _> such insecure methods_
|
| No, your security model is flawed. curl-to-bash is equivalent
| to running arbitrary code on your device. If the Rust
| developers wanted to root you, they could easily just put the
| backdoor into the compiler binary that you are asking to
| receive from them.
| mustache_kimono wrote:
| > curl | sh is literally the #1 recommended and most common
| way to install the rust development toolchain
|
| Rust provides _a uniform way_ to install on any Unix you say?
| Compared to polyglot boarding house which is Linux package
| management?
|
| > because it changes too rapidly to effectively be in any
| repos
|
| rustup is also installable via your package manager, but, if
| it isn't, that's kinda your own distro's problem. The problem
| is that Linux is non-uniform. The problem is not Rust for
| providing a uniform, lowest common denominator, method for
| Unix. Notice Windows doesn't have the same problem.
|
| See: https://rust-
| lang.github.io/rustup/installation/other.html
|
| > It's crazy that a language that prioritizes security so
| highly in it's design itself is only compiled through such
| insecure methods.
|
| Compiled?
|
| Please explain the material security differences between the
| use of rustup.rs method vs. using a package manager.
|
| I'll wait.
| jjgreen wrote:
| Splendid idea, especially since "curl | bash" can be detected on
| the server [1] (which if compromised could serve hostile content
| to only those who do it)
|
| [1]
| https://web.archive.org/web/20250622061208/http://idontplayd...
| falcor84 wrote:
| Yes, ... but if the server is compromised, they could also just
| inject malware directly into the binary that it's installing,
| right? As I see it, at the end of the day you're only safe if
| you're directly downloading a package whose hash you can
| confirm via a separate trusted source. Anything else puts you
| at the mercy of the server you're downloading from.
| sim7c00 wrote:
| depending on what you run one method might have more success
| than another. protections for malicious scripts vs. modified
| binaries are often different tools or different components of
| the same tool that can have varying degrees of success.
|
| you could also use the script to fingerprint and beacon to
| check if the target is worth it and what you might want to
| inject into said binary if thats your pick.
|
| still i think i agree, if you gonna trust a binary from that
| server or a scripts its potato potato...
|
| check what you run before you run it with whatever tools or
| skills u got and hope for the best.
|
| if you go deepest into this rabbithole, you cant trust your
| hard disk or network card etc. so its then at some point just
| impossible to do anyhting. microcode patches, malicious
| firmwares, whatever.
|
| for pragmatic reasons line needs to be drawn. if your
| paranoid good luck and dont learn too much about
| cybersecurity, or you will need to build your own computer :p
| IshKebab wrote:
| This is one of those theoretical issues that has absolutely no
| practical implications.
| gchamonlive wrote:
| I like that vet, which wraps the `curl | bash` pattern, can be
| installed via the `curl | bash` pattern but it's documented under
| https://github.com/vet-run/vet?tab=readme-ov-file#the-trusti....
|
| I don't see it in arch's aur though. That would be my preferred
| install method. Maybe I'd take a look at it later if it's really
| not available there.
| Sanzig wrote:
| I wonder if domain validation might be a good addition to this?
| You could encode a public key in a TXT record for the domain, and
| if present, vet could check a signature in the shell script
| against the key in the TXT record. It wouldn't stop attacks where
| the owner lost control of the DNS records, but it would stop the
| "webserver hijack" attack vector.
| goku12 wrote:
| That's what they do in DKIM signing of emails. But if you want
| to go that route, there are easier solutions. For example,
| Github and Gitlab expose your SSH keys at a specific URL. You
| could use those (for ssh signing) if you trust the account.
| Another even easier method is to use something like cosign
| (sigstore) if you trust a PKI. Or you could use WebFinger to
| advertise signify keys or Web Key Directory (WKD) to expose
| OpenPGP keys, etc.
| maxboone wrote:
| TLSA records exist, but are for the entire server rather than a
| single binary or script.
| tyingq wrote:
| An option to run the potentially harmful script in a rootless
| container, then dump filesystem diffs, audit events, etc...might
| be helpful.
|
| I get containers aren't perfect isolation, but...
| eptcyka wrote:
| Could do it in a VM too.
| ilyagr wrote:
| One option is https://github.com/binpash/try
|
| It is Linux-only, though.
| nailer wrote:
| Reminder that the pattern has the same risk as downloading
| software that you haven't audited and verified the binary matches
| the source.
| mrspuratic wrote:
| Reminder that there is the reductive argument that basically
| everything you download is arbitrary code, but throwing away
| the code that is run seems uniquely silly.
| aflag wrote:
| How is it silly to throw away code that you'll run only once?
| nailer wrote:
| > Reminder that there is the reductive argument that
| basically everything you download is arbitrary code
|
| I'm not sure why you think pointing out the risk of regular
| unaudited unverifiable downloads is reductive as you haven't
| provided any supporting arguments, only snark. You seem like
| a cunt.
|
| > throwing away the code that is run seems uniquely silly.
|
| Neither traditional downloads and curl | bash are commonly
| stored long term for analysis.
| pxeger1 wrote:
| My problem with curl|bash is not that the script might be
| malicious - the software I'm installing could equally be
| malicious. It's that it may be written incompetently, or just not
| with users like me in mind, and so the installation gets done in
| some broken, brittle, or non-standard way on my system. I'd much
| rather download a single binary and install it myself in the
| location I know it belongs in.
| jerf wrote:
| I've also seen really wonderfully-written scripts that, if you
| read them manually, allow you to change where whatever it is is
| installed, what features it may have, optional integration with
| Python environments, or other things like that.
|
| I at least skim all the scripts I download this way before I
| run them. There's just all kinds of reasons to, ranging all the
| way from the "is this malicious" to "does this have options
| they're not telling me about that I want to use".
|
| A particular example is that I really want to know if you're
| setting up something that integrates with my distro's package
| manager or just yolo'ing it somewhere into my user's file
| system, and if so, where.
| AndyMcConachie wrote:
| 100% agree. The question of whether I should install lib-X
| for language-Y using Y's package management system or the
| distribution's package management system is unresolved.
| Diti wrote:
| It's solved by Nix. Whichever package management you choose
| (nixpkgs or pip or whatever), the derivation should have
| the same hash in the Nix store.
|
| (Nix isn't the solution for OP's problems though - Nix
| packages are unsigned, so it's it's basically backdoor-as-
| a-service.)
| sim7c00 wrote:
| right? read before u run. if you cant make sense of it all,
| dont run. if you can make sense of it all, you're free to
| refactor it to your own taste :) saves some time usually. as
| you say, a lot are quite nicely written
| groby_b wrote:
| > read before u run
|
| Lovely sentiment, not applicable when you actually work on
| something. You read your compiler/linker, your OS, and all
| libraries you use? Your windowing system? Your web browser?
| The myriad utilities you need to get your stuff done? And
| of course, you've read "Reflections on trusting trust" and
| disassembled the full output of whatever you compile?
|
| The answer is "you haven't", because most of those are too
| complex for a single person to actually read and fully
| comprehend.
|
| So the question becomes, how do you extend trust. What
| makes a shell script untrustworthy, but the executable you
| or the script install trustworthy?
| spookie wrote:
| Binaries in the Linux world are usually retrieved the
| "Official Way". You use a distro. Therefore you trust
| "them" and how they operate their package manager.
|
| This is the "Unofficial Way".
| inetknght wrote:
| > _I 've also seen really wonderfully-written scripts that_
|
| I'll take a script that passes `shellcheck ./script.sh` (or,
| any other static analysis) first. I don't like fixing other
| people's bugs in their installation scripts.
|
| After that, it's an extra cherry on top to have everything
| configurable. Things that aren't configurable go into a
| container and I can configure as needed from there.
| shadowgovt wrote:
| Much of the reason `curl | bash` grew up in the Linux ecosystem
| is that "single binary that just runs" approach isn't really
| feasible (1) because the various distros themselves don't
| adhere to enough of a standard to support it. Windows and
| MacOS, being mono-vendor, have a sufficiently standardized
| configuration that install tooling that just layers a new
| application into your existing ecosystem is relatively
| straightforward: they're not worrying about what audio
| subsystem you installed, or what side of the systemd turf war
| your distro landed on, or which of three (four? five?) popular
| desktop environments you installed, or whether your `/dev`
| directory is fully-populated. There's one answer for the
| equivalent of all those questions on Mac and Win so shoving
| some random binary in there Just Works.
|
| Given the jungle that is the Linux ecosystem, that bash script
| is doing an _awful_ lot of compatibility verification and
| alternatives selection to stand up the tool on your machine.
| And if what you mean is "I'd rather they hand me the binary
| blob and I just hook it up based on a manifest they also
| provided..." Most people do not want to do that level of
| configuration, not when there are two OS ecosystems out there
| that Just Work. They understandably want their Linux distro to
| Just Work too.
|
| (1) feasible _traditionally._ Projects like snap and flatpak
| take a page from the success Docker has had and bundle the
| executable with its dependencies so it no longer has to worry
| about what special snowflake your "home" distro is, it's
| carrying all the audio / system / whatever dependencies it
| relies upon with it. Mostly. And at the cost of having all
| these redundant tech stacks resident on disk and in memory and
| only consolidateable if two packages are children of the same
| parent image.
| fouc wrote:
| I first encountered `curl | bash` in the macOS world, most
| specifically with installing the worst package manager ever,
| homebrew, which first came out in 2009. Since then it's
| spread.
|
| I call it the worst because it doesn't support installing
| specific versions of libraries, doesn't support downgrading,
| etc. It's basically hostile and forces you to constantly
| upgrade everything, which invariably leads to breaking a
| dependency and wasting time fixing that.
|
| These days I mostly use devbox / nix at the global level and
| mise (asdf compatible) at the project level.
| tghccxs wrote:
| Why is homebrew the worst? Do you have a recommendation for
| something better? I default to homebrew out of inertia but
| would love to learn more.
| CharlesW wrote:
| MacPorts is a good alternative, but you'll find that
| Homebrew is absolutely not the worst. Personally, I find
| _brew_ fast and reliable. Look at _mise_ (`brew install
| mise`) for managing any developer dependencies.
| https://mise.jdx.dev/
| fouc wrote:
| Lately I've been using devbox (nix wrapper) for my
| homebrew-like needs via "devbox global add <whatever>",
| for project specific setup I stick with mise (asdf-
| compatible)."
|
| I don't like homebrew because I've been burnt multiple
| times because it often auto-updates when you least want
| it to and breaks project dependencies.
|
| And there's no way to downgrade to a specific version.
| Real package managers typically support versioning.
| antihero wrote:
| If you're depending on specific versions, don't use a
| general system package manager, use something like mise
| or asdf.
| chme wrote:
| nix possible with lix, if you can stomach nix syntax.
| snickerdoodle12 wrote:
| apt and yum/dnf are pretty great
| ryao wrote:
| I am a fan of Gentoo Prefix. Others like pkgsrc.
| xmodem wrote:
| I've been using MacPorts since before homebrew existed
| and never switched away.
| ryandrake wrote:
| Ironic, because macOS's package management system is
| _supposed to be_ the simplest of all! Applications are
| _supposed_ to just live in /Applications or
| ~/Applications, and you're _supposed_ to be able to cleanly
| uninstall them by just deleting their single directory. Not
| all 3rd party developers seem to have gotten that memo, and
| you frequently see crappy and unnecessary "installers" in
| the macOS world.
|
| There may be good or bad reasons why Homebrew can't use the
| standard /Applications pattern, but did they have to go
| with "curl | bash"?
| CharlesW wrote:
| > _...did they have to go with "curl | bash"?_
|
| That's one of many options, documented at the first text
| link of the home page. https://docs.brew.sh/Installation
| ryandrake wrote:
| Wow, they even have a .pkg installer. Had no idea. Is
| this new?
| CharlesW wrote:
| Without going too far down the rabbit hole, it looks like
| the maintainers added it in 2023. In the process, I was
| reminded that the installer initially required Ruby! ( _/
| usr/bin/ruby -e "$(curl..._)
|
| FYI, _mas_ is the equivalent of a package manager for
| macOS apps (a.k.a. a CLI for App Store).
| https://github.com/mas-cli/mas
|
| Other than _brew_ , I use _mise_ for everything I can.
| https://mise.jdx.dev/
| Wowfunhappy wrote:
| The Applications folder system _does_ work really well
| for GUI apps! It 's not really made for command line
| apps.
|
| For command line apps, the equivalent would probably be
| statically-compiled binaries you can just drop somewhere
| in your PATH, e.g. /usr/local/bin/. For programs that are
| actually built this way (which I would personally call
| "the correct way") this works great!
| thewebguyd wrote:
| > Not all 3rd party developers seem to have gotten that
| memo
|
| This frustrates me to no end on macOS. Not only do you
| see crappy installers like you said, but a ton of
| applications now aren't even self contained in
| ~/Applications like they should be.
|
| Apps routinely shit all over ~/Library when they don't
| need to, and don't clean up after themselves so just
| deleting the bundle, while technically 'uninstalls' it,
| you still have stuff left over, and it can eat up disk
| space fast. Same crap that Windows installers do, where
| they'll gladly spread the app all over your file system
| and registry but the uninstaller doesn't actually keep
| track of what went where so it'll routinely miss stuff.
| At least Windows as a built-in disk clean up tool that
| can recognize some of this for you, macOS will just
| happily let apps abuse your file system until you have to
| go digging.
|
| Package managers on Linux solved this problem many, many
| years ago and yet we've all collectively decided to just
| jump on the curl | bash train and toss the solution to
| the curb because...reasons?
| ryandrake wrote:
| Yep, same problem on Windows. It's almost always a
| mistake to give 3rd party developers unrestricted access
| to your filesystem, because they don't care and will shit
| their files all over it.
|
| I wish more applications were distributed by the Mac App
| Store, because I believe App Store distributed apps are
| more strongly sandboxed and may not allow developers to
| abuse your system like this.
| ChocolateGod wrote:
| Mac apps outside the app store can still be sandboxed,
| but they have to be signed.
| shadowgovt wrote:
| "Reasons" is "Nobody wants to wait for the package
| maintainers to decide that their favorite new shiny toy
| is enough a priority to update it to a version recent
| enough to match the online documentation for the new
| shiny toy," mostly.
|
| As I mentioned somewhere side-thread: Debian Unstable is
| only three minor versions behind the version of Rust that
| the Rust team is publishing as their public release, but
| Debian Stable is three years old. For some projects, that
| dinosaur-times speed. If I want to run Debian Stable for
| everything _except Rust,_ I 'm curl-bashing it.
| ryandrake wrote:
| As a user, if you need to run recent versions of your
| tools, I'd argue Debian (at least Debian Stable) is not
| for you. Luckily we have many choices among Linux
| distributions!
| stouset wrote:
| Yes! What I really want from something like this is sandboxing
| the install process to give me a guaranteed _uninstall_
| process.
| hsbauauvhabzb wrote:
| Why would you possibly want to remove my software?
| ChocolateGod wrote:
| This reminded me how if you wanted to remove something like
| cPanel back in the day your really only option was to just
| reinstall the whole OS.
| mjmas wrote:
| tinycorelinux reinstalls its extensions into a tmpfs every
| boot which works nicely. (and you can have different lists of
| extensions that get loaded)
| mingus88 wrote:
| My problem with it is that it encourages unsafe behavior.
|
| How many times will a novice user follow that pattern until
| some jerk on discord drops a curl|bash and gets hits
|
| IRC used to be a battlefield for these kinds of tricks and we
| have legit projects like homebrew training users it's normal to
| raw dog arbitrary code direcly into your environment
| SkiFire13 wrote:
| What would you consider a safer behaviour for downloading
| programs from the internet?
| thewebguyd wrote:
| Use your distro's package manager and repos first and
| foremost. Flatpak is also a viable alternative to
| distribution, and if enabled, comes along with some level
| of sandboxing at least.
|
| "Back in the day" we cloned the source code and compiled
| ourself instead of distributing binaries & install scripts.
|
| But yeah, the problem around curl | bash isn't the delivery
| method itself, it's the unsafe user behavior that generally
| comes along with it. It's the *nix equivalent of
| downloading an untrusted .exe from the net and running it,
| and there's no technical solution for educating users to be
| safe.
|
| Safer behavior IMO would be to continue to encourage the
| use of immutable distros (Fedora silverbue and others). RO
| /, user apps (mostly) sandboxed, and if you do need to run
| anything untrusted, it happens inside a distrobox
| container.
| sim7c00 wrote:
| a lot of useful packages are not in package managers, or
| are in old versions that lack features u need. so its
| quite common to need to get around that...
| hsbauauvhabzb wrote:
| R/O root means a a binary will fail to install, but won't
| stop my homedir being backdoored in a DD Orion to the
| huge waste of time that attempting an RO root would be.
| papichulo2023 wrote:
| Funny enough clone and compile is easier now than ever
| before. You can ask a llm to create a docker to compile
| any random program and most of the time will be okay.
| BHSPitMonkey wrote:
| I've installed untold thousands of .deb packages in my
| lifetime - often "officially" packaged by Debian or
| Ubuntu, but in many cases also from a software vendor's
| own apt repository.
|
| Almost every one contains preinst or postinst scripts
| that are run as root, and yet I can count on zero hands
| the number of times I've opened one up first to see what
| it was actually doing.
|
| At least a curlbash that doesn't prompt me for my
| password is running as an unprivileged user! /shrug
| bawolff wrote:
| Literally anything else.
|
| Keep in mind that its possible to detect when someone is
| doing curl | bash and only send the malicious code when
| curl is being piped, to make it very hard to detect.
| SoftTalker wrote:
| curl | tee foo.sh
|
| and then inspect foo.sh and then (maybe) cat foo.sh |
| bash
|
| Does that avoid the issue?
| broken-kebab wrote:
| Yes, but will you do it really?
| codedokode wrote:
| Software should run in a sandbox. Look at Android for
| example.
| mingus88 wrote:
| You are essentially asking what is safer than running
| arbitrary code from the internet sight unseen directly into
| your shell and I guess my answer would be any other
| standard installation method!
|
| The OS usually has guardrails and logging and audits for
| what is installed but this bypasses it all.
|
| When you look at this from an attackers perspective, it's
| heaven.
|
| My mom recently got fooled by a scammer that convinced her
| to install remote access software. This curl pattern is the
| exact same vector, and it's nuts to see it become
| commonplace
| troupo wrote:
| > My problem with it is that it encourages unsafe behavior.
|
| Then why don't Linux distributions encourage safe behaviour?
| Why do you still need sudo permissions to install anything on
| most Linux systems?
|
| > How many times will a novice user follow that pattern until
| some jerk on discord
|
| I'm not a novice user and I _will_ use this pattern because
| it 's frankly easier and faster, especially when the current
| distro doesn't have some combination of things installed, or
| doesn't have certain packages, or...
| keyringlight wrote:
| I think a lot of this comes down to assumptions about the
| audience and something along the lines of "it's not a
| problem until it is". It's one aspect I wonder about with
| migrants from windows, and all the assumptions or habits
| they bring with them. Microsoft has been trying to put
| various safety rails around users for the past 20 years
| since they started taking security more seriously with xp,
| and that gets pushback every time they try and restrict or
| warn.
| ChocolateGod wrote:
| > Why do you still need sudo permissions to install
| anything on most Linux systems?
|
| You don't with Flatpak or rootless containers, that's
| partially why they're being pushed so much.
|
| They don't rely on setuid for it either
| johnisgood wrote:
| Flatpak and AppImage.
|
| Or download & compile & install to a PREFIX (e.g.
| ~/.local/pkg/), and use a symlink-manager to install to
| e.g. ~/local (and set MANPATH accordingly, too). Make
| sure PATH contains ~/.local/bin, etc. It does not work
| with Electron apps though. I do "alias foo="cd ... &&
| ./foo".
| umanwizard wrote:
| > Why do you still need sudo permissions to install
| anything on most Linux systems
|
| Not guix :)
|
| One of the coolest things about it.
| nikisweeting wrote:
| This is always the beef that I've had with it. Particularly the
| lack of automatic updates and enforced immutable monotonic
| public version history. It leads to each program implementing
| its own non-standard self-updating logic instead of just
| relying on the system package managers.
| https://docs.sweeting.me/s/against-curl-sh
| IgorPartola wrote:
| This exactly. You never know what it will do. Will it simply
| check that you have Python and virtualenv and install
| everything into a single directory? Or will it hijack your
| system by adding trusted remote software repositories? Will it
| create new users? Open network ports? Install an old version of
| Java it needs? Replace system binaries for "better" ones?
| Install Docker?
|
| Operating systems already have standard ways of distributing
| software to end users. Use it! Sure maybe it takes you a little
| extra time to do a one off task of adding the ability to build
| Debian packages, RPM, etc. but at least your software will
| coexist nicely with everything else. Or if your software is
| such a prima-donna that it needs its own OS image, package it
| in a Docker container. But really, just stop trying to reinvent
| the wheel (literally).
| 1vuio0pswjnm7 wrote:
| Many times a day both in scripts and interactively I use a
| small program I refer to as "yy030" that filters URLs from
| stdin. It's a bit like "urlview" but uses less complicated
| regex and is faster. There is no third party software I use
| that is distributed via "curl|bash" and in practice I do not
| use curl or bash, however if I did I might use yy030 to extract
| any URLs from install.sh something like this
| curl https://example.com/install.sh|yy030
|
| or curl https://example.com/install.sh >
| install.sh yy030 < install.sh
|
| Another filter, "yy073", turns a list of URLs into a simple web
| page. For example, curl
| https://example.com/install.sh|yy030|yy073 > 1.htm
|
| I can then open 1.htm in an HTML reader and select any file for
| download or processing by any program according to any file
| associations I choose, somewhat like "urlview".
|
| I do not use "fzf" or anything like that. yy030 and yy073 are
| small static binaries under 50k that compile in about 1 second.
|
| I also have a tiny script that downloads a URL received on
| stdin. For example, to download the third URL from install.sh
| to 1.tgz yy030 < install.sh|sed -n 3p|ftp0
| 1.tgz
|
| "ftp" means the client is tnftp
|
| "0" means stdin
| jraph wrote:
| Nice. Next step: provide an interactive shell (plugin) that
| detects curl | (ba)sh and suggests running vet instead.
| networked wrote:
| You can also use _vipe_ from moreutils: curl -sSL
| https://example.com/install.sh | vipe | sh
|
| This will open the output of the _curl_ command in your editor
| and let you review and modify it before passing it on to the
| shell. If it seems shady, clear the text.
|
| _vet_ looks safer. (Edit: It has the diff feature and defaults
| to not running the script. However, it also doesn 't display a
| new script for review by default.) The advantage of _vipe_ is
| that you probably have moreutils available in your system 's
| package repositories or already installed.
| TZubiri wrote:
| Huh
|
| Why not just use the tools separately instead of bringing a
| third tool for this.
|
| Curl -o script.sh
|
| Cat script.sh
|
| Bash script.sh
|
| What a concept
| networked wrote:
| What it comes down to is that people want a one-liner.
| Telling them they shouldn't use a one-liner doesn't work.
| Therefore, it is better to provide a safer one-liner.
|
| This assumes that securing `curl | sh` separately from the
| binaries and packages the script downloads makes sense. I
| think it does. Theoretically, someone can compromise your
| site http://example.com with the installation script
| https://example.com/install.sh but not your binary downloads
| on GitHub. Reviewing the script lets the user notice that,
| for example, the download is not coming from the project's
| GitHub organization.
| adolph wrote:
| Same but less instead of cat so my fingers stay in the
| keyboard.
|
| Vet, vite, etc are kind of like kitchen single-taskers like
| avocado slicer-scoopers. Surely some people get great value
| out of them but a table-knife works just fine for me and
| useful in many task flows.
|
| I'd get more value out of a cross-platform copy-paster so I'm
| not skip-stepping in my mind between pbpaste and xclip.
| hsbauauvhabzb wrote:
| Have you tried aliases?
| adolph wrote:
| For pbpaste/pbcopy and xclip? I've considered it and
| haven't decided how to do it yet given differences in how
| they work. Do you have one?
|
| https://linux.die.net/man/1/xclip
|
| https://ss64.com/mac/pbcopy.html
|
| https://man.openbsd.org/xclipboard.1
| bawolff wrote:
| If you are really paranoid you should use cat -v, as
| otherwise terminal control characters can hide the malicious
| part of the script.
| panki27 wrote:
| At this point, the whole world is just a complexity Olympiad
| johnfn wrote:
| Am I missing something? Even if you do `vet foobar-downloader.sh`
| instead of `curl foobar-downloader.sh | bash`, isn't your next
| command going to be to execute `foobar` regardless, "blindly
| trusting" that all the source in the `foobar` repository isn't
| compromised, etc?
| lr0 wrote:
| No it says that it will show you the script first so you can
| review it. What I don't get is why do you nee d a program for
| this, you can simple curl the script to a file, `cat` it, and
| review it.
| simonw wrote:
| It shows you the installation script but that doesn't help
| you evaluate if the binary that the script installs is itself
| safe to run.
| dotancohen wrote:
| Right, this tool does one thing - make it easy to see the
| script. Another tool does something else. That's kind of
| the UNIX Philosophy.
| geysersam wrote:
| Yes but even if you inspect the code of the installation
| script the program you just installed might still be
| compromised/malicious? It doesn't seem more likely that an
| attacker managed to compromise an installation script, than
| that they managed to compromise the released binary itself.
| loloquwowndueo wrote:
| If you're just going to run it blindly you don't need vet. It's
| not automatic - just gives you a chance to review the script
| before run I h it.
| do_not_redeem wrote:
| It's crazy that so much ink is spilled on curl | bash, but then
| those same people will happily run the 50MB binary it downloads
| for you without a second thought. Someone explain this to me,
| please.
|
| Let's consider rust: https://www.rust-lang.org/tools/install
|
| Specifically, consider these two files:
|
| A. a shell script, written by the Rust core developers, hosted on
| the Rust official website behind TLS
|
| B. a compiler binary, written by the Rust core developers, hosted
| on the Rust official website behind TLS
|
| Why is everyone so afraid of A, but not afraid of B?
| exitb wrote:
| I was hoping this would have a curl | bash installer. Was not
| disappointed!
| Galanwe wrote:
| The whole point of "curl|bash" is to skip dependency on package
| managers and install on a barebone machine. Installing a tool
| that allow to install tools without installation tool is...
| chii wrote:
| but then it needs to come with a curl|bash uninstall tool. Most
| of these install scripts are just half the story, and the
| uninstalling part doesn't exist.
| ryandrake wrote:
| Sadly, a great many 3rd party developers don't give a single
| shit about uninstallation, and won't lift a finger to do it
| cleanly, correctly and completely. If their
| installer/packager happens to do it, great, but they're not
| going to spend development cycles making it wonderful.
| thewebguyd wrote:
| This is why its so upsetting over in Linux land how so many
| people are just itching to move away from distro package
| managers and package maintainers. Curl | bash is everywhere
| now because "packaging is hard" and devs can't be arsed to
| actually package their software for the OS they developed
| it for.
|
| Like, yeah I get it - it's frustrating when xyz software
| you want isn't in the repos, but (assuming it's open
| source) you're also welcome to package it up for your
| distro yourself. We already learned lessons from Windows
| where installers and "uninstallers" don't respect you or
| your filesystem. Package managers solved this problem many,
| many years ago.
| maccard wrote:
| What package manager would you recommend that allows a
| one line install on windows (wsl), Mac, debian, fedora
| and arch?
| jrpear wrote:
| For those install scripts which allow changing the install
| prefix (e.g. autoconf projects---though involving a built
| step too), I've found GNU Stow to be a good solution to the
| uninstall situation. Install in `/usr/local/stow` or
| `~/.local/stow` then have Stow set up symlinks to the final
| locations. Then uninstall with `stow --delete`.
| ndsipa_pomu wrote:
| Most of the time I've seen curl|bash, it is to add a repository
| source to the package manager (debian/ubuntu).
| nikisweeting wrote:
| this is the only sane way to do it, curl|sh should just
| automate the package manager commands
| baq wrote:
| we've been curl | bashing software on windows since forever, it
| was called 'downloading and running an installer' and yes, there
| was the occasional malware. the solution to that was antivirus
| software. at this point even the younger hners should see how the
| wheel of history turns.
|
| meanwhile, everyone everywhere is npm installing and docker
| running without second thoughts.
| simonw wrote:
| "the solution to that was antivirus software"
|
| How well did that work out?
| esafak wrote:
| Great. It motivated me to drop kick Windows and move to Linux
| and MacOS.
| nicce wrote:
| Do you know how deeply integrated anti-virus is on macOS?
| esafak wrote:
| No, and I haven't encountered a virus either. During the
| Microsoft era viruses frequently did the rounds, becoming
| water cooler talk.
| maccard wrote:
| That's mostly because applications themselves got way
| more secure.
| bongodongobob wrote:
| As someone who manages 1000s of devices, great.
| thewebguyd wrote:
| > How well did that work out?
|
| Classic old school antivirus? Not great, but did catch some
| things.
|
| Modern EDR systems? They work extremely well when properly
| set up and configured across a fleet of devices as it's
| looking for behavior and patterns instead of just going off
| of known malware signatures.
| panki27 wrote:
| If modern EDR systems are so great without relying on
| classical signature matching, then why are they still doing
| it? Why do they keep fetching "definition databases" as
| often as possible?
|
| ... because it's the only thing that somewhat works. From
| my personal experience, the heuristic and "AI-based"
| approaches lead to so many false positives, it's not even
| worth pursuing them.
|
| The best AV remains and will always be common sense.
| maccard wrote:
| My last job had a modern endpoint detection system running
| on it and my 7 year old MacBook was as quick as my top of
| the line i9 processor because of it. I have never seen
| software destroy a systems performance as much as carbon
| black, crowdstrike and cortex do.
|
| They're also not exactly risk free - [0]
|
| [0] https://en.m.wikipedia.org/wiki/2024_CrowdStrike-
| related_IT_...
| Cthulhu_ wrote:
| "everyone else" is using an app store that has (read: should
| have) vetted and reviewed applications.
| inanutshellus wrote:
| > meanwhile, everyone everywhere is npm installing and docker
| running without second thoughts.
|
| Well... _sometimes_ like, say, _yesterday_ [1], there 's a
| second thought... [1]
| https://www.bleepingcomputer.com/news/security/npm-package-is-
| with-28m-weekly-downloads-infected-devs-with-malware/
| ndsipa_pomu wrote:
| At least with curl and bash, the code is human readable, so
| it's easy to inspect it as long as you have some basic
| knowledge of bash scripts.
| fragmede wrote:
| software running in docker's a bit more sandboxed than running
| outside of it, even if it's not bulletproof.
| bongodongobob wrote:
| Tired of pointless "security" nonsense. This is silly.
| lorenzohess wrote:
| curl github.com/vet-run/install.sh | bash
| sgc wrote:
| Given the conversations in this thread about the annoying package
| management that leads to so much use of curl | bash, I have a
| question: Which Linux distro is the least annoying in this
| regard? Specifically, I mean 1) packages are installed in a
| predictable location (not one of 3-5 legacy locations, or split
| between directories); 2) configuration files are installed in a
| predictable location; 3) Packages are up to date; 4) There is a a
| large selection of software in the repositories; 5) Security is a
| priority for the distro maintainers; 6) It's not like pulling
| teeth if I want/need to customize my setup away from the
| defaults.
|
| I have always used Debian / Ubuntu because I started with my
| server using them and have wanted to keep the same tech stack
| between server and desktop - and they have a large repository
| ecosystem. But the fragmentation and often times byzantine layout
| is really starting to grind my gears. I sometimes find a couple
| overlapping packages installed, and it requires research and
| testing to figure out which one has priority (mainly
| networking...).
|
| Certainly, there is no perfect answer. I am just trying to
| discover which ones come close.
| lima wrote:
| The only distros that are cleanly customizable are declarative
| ones approaches like NixOS or guix.
| GrantMoyer wrote:
| Try Arch Linux. It hits all your points except maybe 5.
|
| 1. It symlinks redundant bin and lib directories to /usr/bin,
| and its packages don't install anything to /usr/local.
|
| 2. You can keep most config files in /etc or $XDG_CONFIG_HOME.
| Occasionally software doesn't follow the standards, but that's
| hardly the distro's fault.
|
| 3. Arch is bleeding edge
|
| 4. Arch repos are pretty big, plus thete's the AUR, plus
| packaging software yourself from source or binaries is
| practically trivial.
|
| 5. Security is not the highest priority over usability. You can
| configure SELinux and the like, but they're not on by default.
| See https://wiki.archlinux.org/title/Security.
|
| 6. There are few defaults to adhear to on Arch. Users are
| expected to customize.
| Elfener wrote:
| I switched to NixOS to solve this sort of problem.
|
| Configuration of system-wide things is done in the nix langauge
| in one place.
|
| It also has the most packages of any distro.
|
| And I found packaging to be more approachable than other
| distros, so if something isn't packaged you can do it properly
| rather than just curl|bash-ing.
| speed_spread wrote:
| I'm using Fedora Kinoite with distrobox. My development envs
| are containerized. This makes it easy to prevent tech stacks
| from interfering and also provides some security because any
| damage should be contained to the container. It does add
| initial overhead to the setup but once you get going it's
| great.
| jwilk wrote:
| If bat is not available, vet uses less, which is not a faithful
| pager:
|
| https://github.com/jwilk/unfaithful-less
|
| It seems at least some versions of bat have the same problem, but
| I didn't look into the details.
| evertheylen wrote:
| Another approach I wrote to protect your system from untrusted
| dependencies (for Linux devs): https://evertheylen.eu/p/probox-
| intro/
|
| Happy to hear other people's thoughts!
| xyst wrote:
| Can't recall the last time I used `curl ... | bash` to install
| anything on personal or remote devices.
|
| Switched to nix + home-manager as a package manager to replace
| defacto package managers on some operating systems (ie, darwin
| uses macports or homebrew).
|
| In cases where the package isn't available in nixpkgs, can create
| my own derivation and build it from source.
|
| If I am super paranoid, spin up sandboxed vm with minimal nixos.
| Use nixos-anywhere to setup vm. Install/build suspicious package.
| Then do reconnaissance. Nuke the vm after I am done.
|
| Nix, like any other software, isn't fool proof. Something is
| likely to get through. In that case, identify the malicious
| package in nix store. Update your flake to remove/patch software
| that introduced it. Then nuke the system completely.
|
| Then rebuild system using your declarative system configuration
| without malicious software.
|
| Is nix for everyone? God no, there's a massive learning curve.
| But I will say that once you get past this learning curve, you
| will never need to install anything with this pattern.
| jimmaswell wrote:
| Had there been a single notable incident of curlbash leading to a
| malware outbreak that this would have prevented?
| TZubiri wrote:
| Lol
| stouset wrote:
| No, because if someone can compromise your curlbash, they can
| just as easily compromise the binary package you're installing
| with it.
| ojosilva wrote:
| Funny, I had this need just today, but with a not-so-popular
| GitHub repo I cloned today. Before running it, I opened the
| folder in Cursor and requested a check for suspicious activities,
| which after a good scan of README and source files, Cursor
| reported back that it was ok to proceed.
|
| I think getting an (optional?) AI heads-up before reviewing it
| myself would be great for cURL shell scripts as well. I'm prone
| to not seeing dark patterns in editor, and tools like vet could
| as well be tricked into not seeing the dark pattern, malicious
| intent, or just hazardous code lurking.
| alienbaby wrote:
| I wouldn't quite trust an AI's opinion in wether given code is
| malicious or not, maybe in the future, but not quite yet.
| bugsMarathon88 wrote:
| The solution to executing untrusted code is not to execute more
| untrusted code, especially through a tool which has not itself
| been "vetted".
| djha-skin wrote:
| I love articles like these that show me new tools instead of
| showing me new AI tricks. This is the kind of thing I'm in on
| Hacker News for. I missed the 2010s because people were writing
| tools for other people. Nowadays it's all about how can I get AI
| to write it for me poorly.
| fsckboy wrote:
| a zillion comments here and it's not mentioned yet:
|
| packages are installed as root/admin with elevated privilege
|
| packages are run as ordinarly lusers
|
| this is why curl|bash is a more dangerous thing to do.
|
| traditionally, the people with the root password were experienced
| and trained for this type of analysis, but with personal machines
| this line of defense does not exist
|
| yes, there are scripts also built into package installers. now
| you can understand why there shouldn't be, or at least the post-
| install script can be inspected (this is a major benefit of
| scripts)
|
| all the noise you want to make about how different distros make
| the problem harder is part of the problem if your solution is to
| capitulate to practices which are unsafe-by-design
| aezart wrote:
| I think aside from any safety issues, another reason to prefer a
| deb or something over curl | bash is that it lets your package
| manager know what you're installing. It can warn you about unmet
| dependencies, it knows where all the individual components are
| installed, etc. When I see a deb I feel more confident that the
| software will play nicely with other stuff on the system.
| marssaxman wrote:
| I wonder what this program's `diff` feature is intended for? I
| can't think of a time when I've wanted to run the same install
| script more than once.
| codedokode wrote:
| This shows how bad things are in Linux land and how unfriendly
| Linux is for third-party apps. The idea that someone will package
| every application for every Linux distribution is delusional. The
| proper solution is to provide a standard API and make
| applications against this API. And of course there should be a
| sandbox for third-party apps.
|
| Compare this to Windows where there is a standard API, standard
| set of pre-installed fonts and libraries, you download an exe and
| it "just works". However Windows has no sandbox and is not secure
| at all if you install any third-party apps. There are
| antiviruses, but they cannot guarantee detection of malicious
| code, and do not even try to block less malicious code like
| tracking and telemetry.
|
| One might notice that there are Snap/Flatpak, however the issue
| with them is that the applications there mostly not work properly
| and have lot of bugs. Also they do not sandbox properly, for
| example, do not prevent reading serial numbers of equipment.
| neilv wrote:
| Some municipalities operate relatively safe locations where drug
| addicts can shoot up.
|
| But it the conventional wisdom is that it's better not to shoot
| up at all.
| jrm4 wrote:
| As an old-timer, going through this thread, I must say that
| there's just not enough hate for the whole Windows/Mac OS
| inclination to not want to let users be experimental.
|
| Everyone here is sort of caught up in this weird middle ground,
| where you're expecting an environment that is both safe and
| experimental -- but the two dominant Oses do EVERYTHING THEY CAN
| to kill the latter, which, funny enough, can also make the former
| worse.
|
| Do not forget, for _years_ you have been in a world in which
| Apple and Microsoft do not want you to have any real power.
| lodefende wrote:
| Gog hacker
| lodefende wrote:
| Hahaah sistema opcional?
___________________________________________________________________
(page generated 2025-07-24 23:00 UTC)