4 ms·

It doesnt ever work. Ive yet to see a "curl https://thisshit.net/trust/us/really/we/have/https https://thisshit.net/trust/us/really/we/have/https | bash" scrip

by antocv 10y ago

It doesnt ever work. Ive yet to see a "curl https://thisshit.net/trust/us/really/we/have/https https://thisshit.net/trust/us/really/we/have/https | bash" script which didnt fail for whatever dumb reason, such as only working on specific variants of Ubuntu, with specific packages installed in specific version, and/or RedHat. Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux. Sandstorm.io looking at you. If you are already going to invest in making "an install script" with defined/researched which packages/versions with which your software needs, for various platforms - submit this data to that platform as an debian/{control,etc} to make a .deb or specfile for .rpm or PKGBUILD or whatever, and use the platforms _build tools_ to generate a platform specific package - be a package mantainer if you have to. Another side effect of telling your users to curl | bash, is I wont ever use your software. You didnt make the effort to do the right thing with packaging, why would you have done any better for whatever it is youre trying to do with your shit software? (sandstorm again).

geofft 10y ago
Don't all the same criticisms apply to `./configure && make install`?
- antocv 10y ago
  Sure, so make it clear what curl | bash is, tell your users "we dont have any packages for your system, here is the source and we use X build tool, please do ./configure && make install, or cmake or whatever", that would have been nice. When I have to install packages from source, I have a more secure/locked down linux container, with seccomp applied, dropped capabilities etc, then if I intend to use the the software over longer time, and expect updates, I skim the source and build-system quality, quickly write a PKGBUILD or APKBUILD, build it, install it into its own new container - with iptables filtering outgoing connections, and thats it, sometimes submit the APKBUILD to alpine testing or aur. And all this is easier than curl | bash oh watch it fail for dumb reason in the install script - and I did try that, the time spent troubleshooting the install script is longer than time to sandbox the whole thing as described above. So, if I can do it, why cant the project? Why spend their efforts on writing an install script instead of package-build instructions to various distributions?
  - geofft 10y ago
    For Sandstorm in particular, it doesn't necessarily run inside a container since it is itself a container management / sandbox tool, makes use of seccomp protections, etc. I'm not sure what the best way to sandbox Sandstorm is. Maybe get a separate VM instance. (I am a Sandstorm fan, but I don't have it installed because it wants me to flip some sysctl about user namespaces or something, and I don't currently have a separate machine to do that on)
    - kentonv 10y ago
      > it wants me to flip some sysctl about user namespaces or something FWIW, this is no longer needed! Sandstorm has been updated to work without user namespaces and this installer script change will remove the check from the installer (will probably ship this week): https://github.com/sandstorm-io/sandstorm/pull/2656 https://github.com/sandstorm-io/sandstorm/pull/2656 (You will need to let Sandstorm start as root if you don't want to flip the sysctl, though.)
      - antocv 10y ago
        > You will need to let Sandstorm start as root Joke of today, thanks for the laugh.
        geofft 10y ago
        What do you run as root that isn't accessible to other users on your system, and why are you deploying Sandstorm on this machine? If it's a single-user machine, any process running at any privilege level can trivially get root by editing ~/.bashrc and aliasing the sudo command.
        antocv 10y ago
        Aliasing the sudo command? Are you serious? I dont even have sudo, let alone if I had it, I wouldnt use its dumb caching of credentials/session or "ask no password" "feature". Just because my system is single-user doesnt mean I run every process with that one user, in fact I run firefox as its own user, chrome has its own, mpd as its own user, nginx is its own user and so on. This is basic security practice. If you seriously think that it is so easy to get root just because you can run a process as a normal user - "by aliasing sudo command", then by all means run everything as root, whats the harm or big deal, right? Why do you even have a user which is non-root? Why cant sandstorm run like lighttpd or nginx - as their own user, requiring no capabilites, in fact even syscalls can be revoked from them with seccomp and they will still work fine. All they need is socket api, file system api ( open close create), and some others, no they dont need to load kernel modules, ptrace or open_file_handle_at and so on.
- jlarocco 10y ago
  In theory yes, but in my experience ./configure && make install is a lot more reliable. Projects that recommend piping curl to bash are trying to dumb down the process, and they have a tendency to make too many assumptions about the system it'll be running on.
cbr 10y ago
Hi! I maintain a "curl | bash" installer script [1][2]. such as only working on specific variants of Ubuntu, with specific packages installed in specific version, and/or RedHat Our installer is capable of automatically installing dependencies on current versions of Debian, Ubuntu, and CentOS. If you're running something else it prints out "This doesn't appear to be a deb-based distro or an rpm-based one. Not going to be able to install dependencies. Please install dependencies manually and rerun with --no-deps-check.", which seems pretty reasonable to me? submit this data to that platform as an debian/{control,etc} to make a .deb or specfile for .rpm or PKGBUILD or whatever, and use the platforms _build tools_ to generate a platform specific package - be a package mantainer if you have to Building a binary package for ngx_pagespeed isn't really practical. It needs to depend on nginx, but nginx doesn't have an ABI, so it needs to be built from source alongside your existing nginx or as part of a new nginx install. Getting into the distributions, so that they can build the ngx_pagespeed module at the same time as they build their main nginx would work, and is somewhere I would like to be eventually, but requires a lot of coordination with distros. Another side effect of telling your users to curl | bash, is I wont ever use your software. You didnt make the effort to do the right thing with packaging, why would you have done any better for whatever it is youre trying to do with your shit software? I do think what we've done in this case is "the right thing" in terms of how we should be spending our development time. Our installation page does still offer manual install instructions, however, for people who would rather not run a script. [1] https://developers.google.com/speed/pagespeed/module/build_ngx_pagespeed_from_source https://developers.google.com/speed/pagespeed/module/build_n... [2] https://ngxpagespeed.com/install https://ngxpagespeed.com/install
- antocv 10y ago
  > Our installer is capable of automatically installing dependencies on current versions of So you dirty the system where its supposed to be installed, a server, with gcc, make and friends? > . If you're running something else it prints out "This doesn't appea State so on your documentation/page before telling the user curl | bash, as I wrote in another post here, that is nice. Your script does not support transactionional installations, as it is it can break at any point in the script and leave the target system broken/dirty. With a simple PKGBUILD youd also have solved the "binary ABI" part. If it really is tedious to coordinate with several distros, you can take a shortcut and dont deliver a "pkgspeed-for_nginx_module-1.2.3@v1.2" package but instead a "pkgspeed-1.2.3" which conflicts with the normal nginx package and thats it.
kentonv 10y ago
> Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux. > Sandstorm.io looking at you. That's hardly fair, since the reason the Sandstorm installer fails on Arch is because it explicitly checks for the presence of a required kernel feature, and Arch explicitly doesn't have that feature. The installer script fails intentionally because of the missing feature, not because it is badly written. Shipping an Arch package wouldn't have magically made Sandstorm be able to work without the required kernel features. OTOH, if you build a custom kernel that has the necessary features, the Sandstorm installer will run just fine on Arch. (Coincidentally, we plan to lift this restriction this week, as we recently implemented an alternate sandbox design which doesn't require this feature.)
- antocv 10y ago
  It was badly written, it was checking /etc/lsb-release instead of actually checking for that feature, and I hope you dont rely today on /proc/config for "checking for the feature" since /proc/config is not available but maybe the feature actually is. Anyway good job for fixing it. In any case, I doubt your sandbox today would work in my sandbox. That is kind of the point, why cant you ship an application which runs as a normal user only, why do you require root for everything and assume your sandstorm will be the machine-manager? Last time I tried, you actually recommended curl shit | sudo bash. sudo! Nevermind I hate sudo and dont have it. If you need sudo, take it/ask for it, specifically for that 1 operation, not for whole install script. Maybe thats how its done today?
  - kentonv 10y ago
    > it was checking /etc/lsb-release instead of actually checking for that feature No it wasn't. The install script ran a little program that actually attempted to invoke the system call to see if it failed: https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150ebc97dd55fd53e74a2305a863ab/install.sh#L518 https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150... We have never relied on /etc/lsb-release nor /proc/config. > why cant you ship an application which runs as a normal user only First, we're not shipping an application, we're shipping an application platform which includes a container engine. On systems that have unprivileged user namespaces available, you actually can install and run Sandstorm as a regular user -- no root privileges at all. Unfortunately, Arch explicitly turns off user namespaces in their kernel build. Without user namespaces, we have no choice but to require root privileges, because the Linux system calls for setting up containers require either root or user namespaces. (Note that Sandstorm is careful with its root privs -- most of the system runs as a regular user, calling out to a separate daemon for the specific operations that need root.) If you don't want to give Sandstorm root -- which is perfectly understandable -- and you don't want to enable the kernel features that allow it to be non-root, then you'll need to run it in a dedicated VM. > Last time I tried, you actually recommended curl shit | sudo bash. We have never recommended that.

by antocv 10y ago

geofft 10y ago

Don't all the same criticisms apply to `./configure && make install`?

antocv 10y ago
Sure, so make it clear what curl | bash is, tell your users "we dont have any packages for your system, here is the source and we use X build tool, please do ./configure && make install, or cmake or whatever", that would have been nice. When I have to install packages from source, I have a more secure/locked down linux container, with seccomp applied, dropped capabilities etc, then if I intend to use the the software over longer time, and expect updates, I skim the source and build-system quality, quickly write a PKGBUILD or APKBUILD, build it, install it into its own new container - with iptables filtering outgoing connections, and thats it, sometimes submit the APKBUILD to alpine testing or aur. And all this is easier than curl | bash oh watch it fail for dumb reason in the install script - and I did try that, the time spent troubleshooting the install script is longer than time to sandbox the whole thing as described above. So, if I can do it, why cant the project? Why spend their efforts on writing an install script instead of package-build instructions to various distributions?
- geofft 10y ago
  For Sandstorm in particular, it doesn't necessarily run inside a container since it is itself a container management / sandbox tool, makes use of seccomp protections, etc. I'm not sure what the best way to sandbox Sandstorm is. Maybe get a separate VM instance. (I am a Sandstorm fan, but I don't have it installed because it wants me to flip some sysctl about user namespaces or something, and I don't currently have a separate machine to do that on)
  - kentonv 10y ago
    > it wants me to flip some sysctl about user namespaces or something FWIW, this is no longer needed! Sandstorm has been updated to work without user namespaces and this installer script change will remove the check from the installer (will probably ship this week): https://github.com/sandstorm-io/sandstorm/pull/2656 https://github.com/sandstorm-io/sandstorm/pull/2656 (You will need to let Sandstorm start as root if you don't want to flip the sysctl, though.)
    - antocv 10y ago
      > You will need to let Sandstorm start as root Joke of today, thanks for the laugh.
      - geofft 10y ago
        What do you run as root that isn't accessible to other users on your system, and why are you deploying Sandstorm on this machine? If it's a single-user machine, any process running at any privilege level can trivially get root by editing ~/.bashrc and aliasing the sudo command.
        antocv 10y ago
        Aliasing the sudo command? Are you serious? I dont even have sudo, let alone if I had it, I wouldnt use its dumb caching of credentials/session or "ask no password" "feature". Just because my system is single-user doesnt mean I run every process with that one user, in fact I run firefox as its own user, chrome has its own, mpd as its own user, nginx is its own user and so on. This is basic security practice. If you seriously think that it is so easy to get root just because you can run a process as a normal user - "by aliasing sudo command", then by all means run everything as root, whats the harm or big deal, right? Why do you even have a user which is non-root? Why cant sandstorm run like lighttpd or nginx - as their own user, requiring no capabilites, in fact even syscalls can be revoked from them with seccomp and they will still work fine. All they need is socket api, file system api ( open close create), and some others, no they dont need to load kernel modules, ptrace or open_file_handle_at and so on.
jlarocco 10y ago
In theory yes, but in my experience ./configure && make install is a lot more reliable. Projects that recommend piping curl to bash are trying to dumb down the process, and they have a tendency to make too many assumptions about the system it'll be running on.

cbr 10y ago

Hi! I maintain a "curl | bash" installer script [1][2]. such as only working on specific variants of Ubuntu, with specific packages installed in specific version, and/or RedHat Our installer is capable of automatically installing dependencies on current versions of Debian, Ubuntu, and CentOS. If you're running something else it prints out "This doesn't appear to be a deb-based distro or an rpm-based one. Not going to be able to install dependencies. Please install dependencies manually and rerun with --no-deps-check.", which seems pretty reasonable to me? submit this data to that platform as an debian/{control,etc} to make a .deb or specfile for .rpm or PKGBUILD or whatever, and use the platforms _build tools_ to generate a platform specific package - be a package mantainer if you have to Building a binary package for ngx_pagespeed isn't really practical. It needs to depend on nginx, but nginx doesn't have an ABI, so it needs to be built from source alongside your existing nginx or as part of a new nginx install. Getting into the distributions, so that they can build the ngx_pagespeed module at the same time as they build their main nginx would work, and is somewhere I would like to be eventually, but requires a lot of coordination with distros. Another side effect of telling your users to curl | bash, is I wont ever use your software. You didnt make the effort to do the right thing with packaging, why would you have done any better for whatever it is youre trying to do with your shit software? I do think what we've done in this case is "the right thing" in terms of how we should be spending our development time. Our installation page does still offer manual install instructions, however, for people who would rather not run a script. [1] https://developers.google.com/speed/pagespeed/module/build_ngx_pagespeed_from_source https://developers.google.com/speed/pagespeed/module/build_n... [2] https://ngxpagespeed.com/install https://ngxpagespeed.com/install

antocv 10y ago
> Our installer is capable of automatically installing dependencies on current versions of So you dirty the system where its supposed to be installed, a server, with gcc, make and friends? > . If you're running something else it prints out "This doesn't appea State so on your documentation/page before telling the user curl | bash, as I wrote in another post here, that is nice. Your script does not support transactionional installations, as it is it can break at any point in the script and leave the target system broken/dirty. With a simple PKGBUILD youd also have solved the "binary ABI" part. If it really is tedious to coordinate with several distros, you can take a shortcut and dont deliver a "pkgspeed-for_nginx_module-1.2.3@v1.2" package but instead a "pkgspeed-1.2.3" which conflicts with the normal nginx package and thats it.

kentonv 10y ago

> Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux. > Sandstorm.io looking at you. That's hardly fair, since the reason the Sandstorm installer fails on Arch is because it explicitly checks for the presence of a required kernel feature, and Arch explicitly doesn't have that feature. The installer script fails intentionally because of the missing feature, not because it is badly written. Shipping an Arch package wouldn't have magically made Sandstorm be able to work without the required kernel features. OTOH, if you build a custom kernel that has the necessary features, the Sandstorm installer will run just fine on Arch. (Coincidentally, we plan to lift this restriction this week, as we recently implemented an alternate sandbox design which doesn't require this feature.)

antocv 10y ago
It was badly written, it was checking /etc/lsb-release instead of actually checking for that feature, and I hope you dont rely today on /proc/config for "checking for the feature" since /proc/config is not available but maybe the feature actually is. Anyway good job for fixing it. In any case, I doubt your sandbox today would work in my sandbox. That is kind of the point, why cant you ship an application which runs as a normal user only, why do you require root for everything and assume your sandstorm will be the machine-manager? Last time I tried, you actually recommended curl shit | sudo bash. sudo! Nevermind I hate sudo and dont have it. If you need sudo, take it/ask for it, specifically for that 1 operation, not for whole install script. Maybe thats how its done today?
- kentonv 10y ago
  > it was checking /etc/lsb-release instead of actually checking for that feature No it wasn't. The install script ran a little program that actually attempted to invoke the system call to see if it failed: https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150ebc97dd55fd53e74a2305a863ab/install.sh#L518 https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150... We have never relied on /etc/lsb-release nor /proc/config. > why cant you ship an application which runs as a normal user only First, we're not shipping an application, we're shipping an application platform which includes a container engine. On systems that have unprivileged user namespaces available, you actually can install and run Sandstorm as a regular user -- no root privileges at all. Unfortunately, Arch explicitly turns off user namespaces in their kernel build. Without user namespaces, we have no choice but to require root privileges, because the Linux system calls for setting up containers require either root or user namespaces. (Note that Sandstorm is careful with its root privs -- most of the system runs as a regular user, calling out to a separate daemon for the specific operations that need root.) If you don't want to give Sandstorm root -- which is perfectly understandable -- and you don't want to enable the kernel features that allow it to be non-root, then you'll need to run it in a dedicated VM. > Last time I tried, you actually recommended curl shit | sudo bash. We have never recommended that.