Drew DeVault
@marcan
TLS provides privacy but not integrity. In case of a server-side exploitation, or simply memory corruption for any other reason ECC failures are not nearly as uncommon as anyone would like to believe!), TLS provides nothing.
In general this practice to installing software with curl | sh is a huge side-step around all of the security and trust that comes built-in to the system package manager, and tends to litter your system with stuff the package manager doesn't know about -- [cotd]
Drew DeVault
@marcan -- how do you uninstall something installed like this?
I know that your use-case is a bit different, though I think you might lean on that difference too heavily to justify this approach. But there is a good reason we train users NOT to do this when they see it and argue against anyone who proliferates and normalizes it.
t. former author of curl | sh installers
Drew DeVault
@malwareminigun t. Microsoft employee
Drew DeVault
@malwareminigun *sigh*
https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html
Billy O'Neal
@drewdevault all bow to our RedHat and Canonical overlords. No thanks.
Billy O'Neal
@drewdevault I don’t see how this is specific to macOS. The only solution presented is “all software must come from the distro” which is a terrible answer.
Drew DeVault
@malwareminigun yeah, I heard. So rinse and repeat the same arguments for why homebrew ought to get their shit together, too.
In any case, as I've said earlier, macOS is a dumpster fire.
Billy O'Neal
@drewdevault homebrew’s installer does curl | sh. 🤷
Billy O'Neal
@drewdevault great, so to ship software you want the distributor to go through approval processes at all N distros.
Oh wait there isn’t such a package manager that does that on macos.
Wait, wasn’t this discussion about curl | sh?
Drew DeVault
@malwareminigun there are at least two, homebrew and macports.
Drew DeVault
@malwareminigun (1) the system should check it for you, as in the case of package managers, which is overwhelmingly the norm on Linux (2) yes
Drew DeVault
@malwareminigun @marcan this is not true if the server is offering up a binary signed by the distributor.
Billy O'Neal
@drewdevault @marcan 1. Ok but who really checks the sig in these scenarios? (Do 99% of users even know how?)
2. If I owned the distributor I probably can get something signed too?
Billy O'Neal
@drewdevault @marcan if the server is exploited whether you put the exploiting script in a file first means nothing. This is running code. The user needs to trust where they get that code.
werdahias
Billy O'Neal
@werdahias @drewdevault Great, that means 2 groups of people have to be convinced to ship anything before one can ship anything.
The amount of folks I deal with who want to ship to Windows, Linux and Mac but drop Linux when they realize it’s actually like supporting at least 5 different platforms (RHEL, Fedora, Debian, Ubuntu, Arch, Alpine, …) is depressing.
Reinventing another package manager just makes N+1 package managers one has to support. This is why we explicitly refuse requests to make vcpkg into an application deployment system, as we don’t want to make the fragmentation of that universe even worse.
werdahias
Billy O'Neal
@drewdevault @werdahias I did. I don’t see how it changed this equation. Saying “Don’t worry about how long it takes distros to ship you” does not solve the problem. I can’t tell customers “sorry, I fixed that bug last year, but your system runs Ubuntu 20.04 or RHEL8 and we haven’t waited around long enough for the unpaid voulentrers that maintain those to ship our update so there’s just nothing I can do for you”.
Drew DeVault
@malwareminigun @werdahias enterprise settings should pick a distro and maintain their own repo for it.
Drew DeVault
@malwareminigun @werdahias read my blog post.
Haelwenn /элвэн/ :triskell:
Billy O'Neal
@lanodan so to ship my software I now need a paid contract with every distro every one of my customers use? That’s great.
Haelwenn /элвэн/ :triskell:
Haelwenn /элвэн/ :triskell:
Billy O'Neal
@lanodan It isn't 'just deb/rpm', since any given deb/rpm often will not install unless it was produced on a matching distro, because the distros pick particular dependencies.
Haelwenn /элвэн/ :triskell:
Billy O'Neal
@lanodan If I make a snap package or similar I don't have to manage that, because my app comes with all its dependencies.
Similarly if my app is a bash script or I can statically link everything that matters.
Again, putting that into an rpm or deb does not fix the original argument, since that rpm or deb won't be signed by the distro. Installing malicious code through an rpm or deb is no different than installing malicious code through curl|sh.
If you require it to be signed by the distro, you are back in 'supporting Linux actually means supporting ~10 different platforms since there are ~5 distros that matter and their different versions are different universes'. This is a big part of why there's almost no commercial software on Linux.
Haelwenn /элвэн/ :triskell:
Billy O'Neal
@lanodan sorry I don’t know why I said snap, I meant flatpak.
Breizh
@malwareminigun @lanodan You need to pay if you want to have a word on how it’s done. You can pay nothing, but then you can’t complain on how they manage your software in their repositories.
So either you do their work yourself (by having your own repository), or you pay them, if you want to have a bit of control on the distribution process.
Breizh
@malwareminigun @lanodan You don’t have to support everything. If the distro’s packagers are in charge of distributing your software, bug reports will first go through the distro’s ticket system - normally, I admit, sometimes it’s not the case, but then you can say “it works here/can’t reproduce, contact your distribution packagers”. If it’s on their side, they’ll fix it, and you won’t hear about it. If they think it’s related to upstream, they’ll report the bug to you, usually after having reproduced it and with potentially much more detail than the end-user. It’s a win-win situation.
Similarly, if the maintainers can’t package your application, perhaps they’ll ticket you for help (or report a problem if it’s because your generic build/deployment process is flawed). But it’s not up to you to test that it works on this distro, or to understand why it doesn’t work for them when it does for others. It’s their job, not yours.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.