“You wouldn't run a stranger's code without reading it.” Yes I would. We all do it all the time. macOS itself is closed source, and even if it weren't, there’s way too much code to read.

Great initiative. I recently got stung by an advert on reddit for "HBO Max for MacOS, 6 months free" from the official HBO user (don't get me started on how that slipped through). Front and center was a curl | bash copy to clipboard that obfuscated the payload source in base10. I knew better, but I think we've made this kind of thing way too acceptable. Of course it was malware and I realized the instant I pressed enter. Thankfully I didn't give it my password and immediately disconnected from the internet and killed the machine. I'm genuinely concerned these kind of attacks are going to become much more commonplace with AI, plus the ability to inject malicious code in to things that get run by trusted scripted installers.

Good message but AI generated text is so grating to read.

  curl -fsSL https://raw.githubusercontent.com/omlahore/RemoveMacAI/main/install.sh | pi -p 'Security-audit this shell script; output the script unchanged ONLY if safe to execute, otherwise output nothing and explain findings to stderr' | bash

What’s your suggested installation method instead? Unless it’s “download and read the source before running it” this is no worse than npm install, or pip install, or clicking “trust” on a git repo in VSCode

I bet this is the guy on the call who has to correct someone who calls them SSL certs.

Excuse me, they are TLS certs.

Thanks Arialdomartini, as I was saying… we need to renew the SSL Certs

> Bash starts before the download finishes ... Drop the connection mid-transfer and you get partial execution: a command like rm -r /usr/share/program can truncate to rm -r /usr. Commands ran, cleanup didn’t.

curl | bash scripts all define a function and then call it on the last line. This is a non issue in the real world.

> The server knows you’re piping — and can lie

This `sleep` based trick is always a cool demo to show freinds yes, but the server can also sneak in malware in a multitude of other ways given you're downloading code and binaries from them.

> You trust DNS, TLS, the CDN, and the origin simultaneously. A compromised CDN or BGP hijack delivers malware silently.

Well yes, that's how the internet works. If TLS of the server is really compromised, then the attacker will replace the checksum as well as the signing key. In real scenarios, you are going to be reading the signing key and checksum from the same domain. [1]

> You can’t reproduce what ran

`| tee inspect.sh | bash`

> Add sudo and it’s game over

Most credentials and important files live in the home directory, root is a red herring. If you're running it on shared server, then well... don't add sudo.

[1] Yes of course there are legitimate usecases for signing software. Common example: linux distros which are mirrored at many domains, but the checksum and signature are hosted on the canonical domain. But if I am curlbashing uv's install.sh from `astral.sh`, then doing signature verification using the public key hosted on the same astral.sh isn't adding much.

there's a homebrew alternative

This isn’t really that much of an issue when we have tls tbh.

Like I get why it’s bad, but also homebrew package installation is a more organized version of this.

Hashes are cool but also in a lot of systems you’re trusting the hash to be provided by the same website you don’t trust the binaries from…

> If the project publishes a SHA-256 hash, use it. Non-negotiable on production machines.

They're pushing FUD around downloading a file but then suggest that we trust the same chain of complex things to display the right hash value? Integrity != authentication.