[theshrike79]

If I serve you a 2000 line unformatted bash script from an URL and tell you to pipe it to bash, will you do it? Should you do it?

Do you have the mental fortitude to format it and go through it line by line looking for possible exploits?

It's 100% trivial to have it run rm or shred on all files you have access to while simultaneously printing correct looking install progress messages.

[mtlynch]

Is the issue with telling people to pipe URL output into bash? Or is the issue with any distribution method that isn't flatpak or something similarly privilege-limited?

I see how flatpak is an improvement, but I don't see how piping into bash is any worse than "install this .deb file / npm package / pip package." If the package author wanted to do something malicious, it's just as easy (if not easier) to put the malicious code in the package itself rather than a bash installer for the package.

[otikik]

What’s the difference between that and downloading and running an installer?

[3np]

If the installer is a precompiled binary, not much, though this is mostly a Windows-ism these days.

If we're considering the same batch script: You can read it,it before running and be sure that the endpoint doesn't dynamically give you different results depending on how you fetch it.

In either case, the proposal here was flatpak, which does provide security benefits like sandboxing.

[jjnoakes]

If you trust the author of tool you are installing and the installer is by the same author, then why wouldn't you trust the installer too?

> It's 100% trivial to have it run rm or shred on all files you have access to while simultaneously printing correct looking install progress messages.

The same is true of the tool itself, too.

[duckmysick]

Yes, hence the trend of moving to sandboxed apps with limited access to your files (and other capabilities).

[jjnoakes]

The install method itself is not unsafe when compared to most other install methods. It gets a bad rap for no reason.