GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:22:31 JST Rich Felker Rich Felker
    • Lona Theartlav

    @marcan @theartlav > not just "someone may sub in a malicious script...

    Not only is that still relevant, just not usually the biggest problem; validating the curlbash antipattern by copying it, even in a context where it's less dangerous, seems bad too.

    In conversation about a year ago from hachyderm.io permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:22:20 JST Rich Felker Rich Felker
      in reply to
      • Jérôme Petazzoni
      • Amber

      @jpetazzo @puppygirlhornypost Yes, it's basically the difference between trusting one party you chose to mediate these things and make good decisions for you, and N parties who at best are sloppy, if they don't have outright conflicts of interest that disqualify them from making these decisions for you.

      In conversation about a year ago permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Jérôme Petazzoni (jpetazzo@hachyderm.io)'s status on Friday, 24-May-2024 04:22:21 JST Jérôme Petazzoni Jérôme Petazzoni
      in reply to
      • Amber

      @puppygirlhornypost @dalias I agree with you; I'm going to try to rephrase my initial question 😅

      Given that virtually all¹ package managers have some way to run arbitrary postinstall scripts (as root!); what makes a deb/rpm/AUR/... better than curl|sh?

      My stance is that if I install packages from "core" repos, I'm probably good, because these maintainers usually care *a lot* and to a fantastic job (at least compared to the average dev trying to package their stuff).

      But with 3rd party stuff…

      In conversation about a year ago permalink
    • Embed this notice
      Amber (puppygirlhornypost@transfem.social)'s status on Friday, 24-May-2024 04:22:22 JST Amber Amber
      in reply to
      • Jérôme Petazzoni

      @dalias@hachyderm.io @jpetazzo@hachyderm.io It defeats the purpose of the package manager which is supposed to be the one deciding what goes where. If you are shipping software standalone that is fine, but you should realize that if you want people to use it with systems that rely heavily on a package manager to do the heavy lifting you should focus on your post installation instructions. Not a minified, code golfed shell script that does god knows what. Let people figure out how to package that in their ecosystem (or, maintain your packages if you want strict control of the process) this is how it has been, this is how it should be, and anyone who deviates should be ousted. https://wiki.archlinux.org/title/PKGBUILD we have things like PKGBUILD on arch, we have all these native to a package manager's ecosystem way of doing "post install" scripts. do not just write some posix shell, or python, or perl script that requires a BUILD TIME dependency just to make your shit work.

      Why is curl | sh bad? Because it's easy to see if it's curl pulling unless someone bothers to type out user agent flags and so on. Would it be bad practice to curl and then review a script? No. That requires the script to be readable though which most of these curl | sh scripts are absolutely not. I am talking about those horrific thousands of lines posix scripts that have multiple cases, falling through because no adequate testing. https://github.com/valvesoftware/steam-for-linux/issues/3671 do not be that person. it's easier to provide instructions of how to configure the software than to maintain a monolithic script that does everything for them. Not to mention that most of the time these scripts exist to bypass package manager ecosystems. cough https://rustup.rs/

      In conversation about a year ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        rustup.rs - The Rust toolchain installer
        The Rust toolchain installer
      2. No result found on File_thumbnail lookup.
        PKGBUILD - ArchWiki
      3. Domain not in remote thumbnail source whitelist: opengraph.githubassets.com
        Moved ~/.local/share/steam. Ran steam. It deleted everything on system owned by user. · Issue #3671 · ValveSoftware/steam-for-linux
        Edit: Please stop posting stupid image memes or unhelpful messages. This interferes with Valve's ability to sift through the noise and see if anyone can figure out what triggers it. This may not be...
    • Embed this notice
      Amber (puppygirlhornypost@transfem.social)'s status on Friday, 24-May-2024 04:22:23 JST Amber Amber
      in reply to
      • Jérôme Petazzoni

      @dalias@hachyderm.io @jpetazzo@hachyderm.io unironically though, really i want you to realize something. I am going to provide an example of why this is the case, and why we have to rely on things such as fakeroot with proot or what have you to sandbox packaging your apps. https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 WHY? Actually horrific this happened, and impacted a non insignificant amount of people installing bumblebee before NVIDIA wanted to play nice.

      In conversation about a year ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: opengraph.githubassets.com
        install script does rm -rf /usr for ubuntu · Issue #123 · MrMEEE/bumblebee-Old-and-abbandoned
        An extra space at line 351: rm -rf /usr /lib/nvidia-current/xorg/xorg causes the install.sh script to do an rm -rf on the /usr directory for people installing in ubuntu. Totally uncool dude!!! The ...
    • Embed this notice
      Amber (puppygirlhornypost@transfem.social)'s status on Friday, 24-May-2024 04:22:25 JST Amber Amber
      in reply to
      • Jérôme Petazzoni

      @dalias@hachyderm.io @jpetazzo@hachyderm.io post install scripts are the bane of any package maintainers' existence.

      In conversation about a year ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:22:26 JST Rich Felker Rich Felker
      in reply to
      • Jérôme Petazzoni

      @jpetazzo My understanding is that the prevalence of tooling for automating deployments to *your own systems* has somehow made people shipping software think they can do the same thing for other people's systems...

      That, or they come from Windows-land where the 🤮 professional thing to do is ship installers rather than self-contained zips that you extract and execute in place that don't touch anything outside their dir.

      In conversation about a year ago permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:22:27 JST Rich Felker Rich Felker
      in reply to
      • Jérôme Petazzoni

      @jpetazzo "Postinstall scripts" are the same evil as curlbash and should not exist.

      There is no excuse for "scripted modification of the user's system". You document what has to be done and either they do that manually, write their own script, or use their trusted distro provider to install it.

      In conversation about a year ago permalink
    • Embed this notice
      Jérôme Petazzoni (jpetazzo@hachyderm.io)'s status on Friday, 24-May-2024 04:22:28 JST Jérôme Petazzoni Jérôme Petazzoni
      in reply to

      @dalias not wanting to be pedantic, but if I build a package (in a sandboxed environment), then install that package, and the postinstall script of the package backdoors my system, how am I being more secure than curl|sh?

      (My stance is that curl|sh per se isn't bad; the key thing is to look at provenance: https on a well-known domain with legit-looking URL = good; anything else = beware. And same thing for any package or any artifact in any form. I'm happy to revise said stance tho!)

      In conversation about a year ago permalink
    • Embed this notice
      Geoffrey Thomas (geofft@mastodon.social)'s status on Friday, 24-May-2024 04:22:29 JST Geoffrey Thomas Geoffrey Thomas
      in reply to
      • Lona Theartlav

      @dalias @marcan @theartlav But there is no such rule! Plenty of projects that are _not_ security clowncars recommend curl|bash for thoughtful reasons. Plenty of projects that are security clowncars ship source tarballs with unreproducible ./configure scripts.

      There is a _perception_ that it's bad, yes. I think a respected project using curl|bash is just as likely to to rehabilitate curl|bash and fix that perception, especially if (as here, as Sandstorm did, etc.) they write about why it's okay.

      In conversation about a year ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:22:29 JST Rich Felker Rich Felker
      in reply to
      • Lona Theartlav
      • Geoffrey Thomas

      @geofft @marcan @theartlav curlbash should not be "rehabilitated". It's *always wrong*, just to varying degrees.

      Your comparison of "unreproducible configure scripts" doesn't work because the scope of those is such that they run fine in a build sandbox where you discard everything but the build artifacts. curlbash on the other hand is full of commands to install packages, modify config files, etc.

      In conversation about a year ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:22:30 JST Rich Felker Rich Felker
      in reply to
      • Lona Theartlav

      @marcan @theartlav The flip side is it detracts from your credibility when you do it. Folks know "curlbash bad, projects recommending it are security clowncars" as a rule but don't understand the subtleties to evaluate "well in this instance it's not as bad".

      In conversation about a year ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:28:21 JST Rich Felker Rich Felker
      in reply to
      • Lona Theartlav
      • Geoffrey Thomas

      @geofft @marcan @theartlav The core problem with curlbash is the *philosophy* - presume the user doesn't know how to admin their own system, install deps they need, etc. and ask them to let a script you wrote play admin on their box. (Along with that, it acts as license *not to document* what the user would need to do things themselves.)

      In conversation about a year ago permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Geoffrey Thomas (geofft@mastodon.social)'s status on Friday, 24-May-2024 04:28:22 JST Geoffrey Thomas Geoffrey Thomas
      in reply to
      • Lona Theartlav

      @dalias @marcan @theartlav One argument in favor of curl|bash: all realistic alternatives - third-party rpm/deb/etc., pip install, building from source, etc. - are just as capable of running arbitrary code but they _look_ less dangerous. curl|bash is honest about its risk and makes people think whether they trust the source.

      If a project can use a sandboxed app store or run on a web page, that's meaningfully better, but almost no project considering curl|bash can do that.

      In conversation about a year ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:32:52 JST Rich Felker Rich Felker
      in reply to
      • Lona Theartlav
      • Geoffrey Thomas

      @geofft @marcan @theartlav The sandbox I use for builds is not claimed to be tight against outright intentional malice, but at least against malice that folks shipping software think is them being "helpful". If you want to play with escapes I'd love to hear your results. https://github.com/richfelker/usand

      In conversation about a year ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: opengraph.githubassets.com
        GitHub - richfelker/usand: usand - convenient and minimal unshare(1)-based sandbox
        usand - convenient and minimal unshare(1)-based sandbox - richfelker/usand
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Friday, 24-May-2024 04:32:53 JST Rich Felker Rich Felker
      in reply to
      • Lona Theartlav
      • Geoffrey Thomas

      @geofft @marcan @theartlav The question is not whether users unaware of the risks of curlbash do that.

      The question is whether users who are aware of the risks have a viable path to install without reverse engineering the curlbash garbage somebody shipped in place of build/installation instructions.

      In conversation about a year ago permalink
    • Embed this notice
      Geoffrey Thomas (geofft@mastodon.social)'s status on Friday, 24-May-2024 04:32:54 JST Geoffrey Thomas Geoffrey Thomas
      in reply to
      • Lona Theartlav

      @dalias @marcan @theartlav Do any users who are not aware of the risks of curl|bash run ./configure in a build sandbox?

      Also what build sandbox do you use? I would like to try to escape it. :)

      In conversation about a year ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

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.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.