3 ms·

I get that alot. But this is actually easier to audit than install.exe or the shell scripts embedded in a .deb or .rpm (which, incidentally, also run as root).

I get that alot. But this is actually easier to audit than install.exe or the shell scripts embedded in a .deb or .rpm (which, incidentally, also run as root). It looks scary, but it really isn't. Or rather, it's no scarier than most of the other ways to add software to the common desktop operating systems. Edit: and for those who care, there are .rpm and .deb packages available, or you can grab the source from github. Pick your poison.

bensummers 14y ago
Obligatory link to "| sudo bash" HN comment: http://news.ycombinator.com/item?id=2427492 http://news.ycombinator.com/item?id=2427492
- markild 14y ago
  I believe that in most common distributions, both curl and wget will be supplied with ca-certificates out of the box. e.g > $ dig +short ssl.example.com > 123.456.789.012 > $ curl -I https://123.456.789.012/foo.bar https://123.456.789.012/foo.bar > curl: (51) SSL: certificate subject name 'ssl.example.com' > does not match target host name '123.456.789.012' Besides that, he makes several good points which I think should speak for themselves.
- columbo 14y ago
  Sounds like most of those would be solved by putting it up on github so you'd git clone the bash repo then execute it.
alexchamberlain 14y ago
Further to bensummer's link, packages allow a package manager to manage the software. Update, delete etc is all taken care of. It also concerns me that the author of security conscious software isn't concerned by this.
- HerraBRE 14y ago
  I take security quite seriously, but I disagree with how you have evaluated the risk from this particular technique. That said, I do consider this to be a temporary measure while the software is maturing to the point that I can get it accepted into the mainstream distros and build proper win/mac packages. That would be better for everyone, both from a usability and security standpoint. We are a very small team (usually just me) and these things take time.
  - subway 14y ago
    Why wait on it to be accepted by the distros? What is stopping you from setting up a small Yum/Apt repo and publishing your GPG key?
    - HerraBRE 14y ago
      You mean like this? :-) https://pagekite.net/wiki/Howto/GNULinux/DebianPackage/ https://pagekite.net/wiki/Howto/GNULinux/DebianPackage/ https://pagekite.net/wiki/Howto/GNULinux/RpmPackage/ https://pagekite.net/wiki/Howto/GNULinux/RpmPackage/ ... this works and is the most conveninient way to use PageKite if you are treating it as part of the OS (so always on, exposing local servers). However, in the context of security and trust, you really should think thrice before installing 3rd party repos like mine - once you have added my repo to your OS, I can upgrade any package on your computer with whatever malicious content I want. So folks who don't trust me and my curl-bash hack really shouldn't trust this sort of solution either. This is why getting third parties to build, package and sign my software and getting into the public repos is the "correct" solution, but doing so didn't make sense while I was rapidly iterating. Things are starting to stabalize now, so I will probably be revisiting this very soon.

bensummers 14y ago

Obligatory link to "| sudo bash" HN comment: http://news.ycombinator.com/item?id=2427492 http://news.ycombinator.com/item?id=2427492

markild 14y ago
I believe that in most common distributions, both curl and wget will be supplied with ca-certificates out of the box. e.g > $ dig +short ssl.example.com > 123.456.789.012 > $ curl -I https://123.456.789.012/foo.bar https://123.456.789.012/foo.bar > curl: (51) SSL: certificate subject name 'ssl.example.com' > does not match target host name '123.456.789.012' Besides that, he makes several good points which I think should speak for themselves.
columbo 14y ago
Sounds like most of those would be solved by putting it up on github so you'd git clone the bash repo then execute it.

alexchamberlain 14y ago

Further to bensummer's link, packages allow a package manager to manage the software. Update, delete etc is all taken care of. It also concerns me that the author of security conscious software isn't concerned by this.

HerraBRE 14y ago
I take security quite seriously, but I disagree with how you have evaluated the risk from this particular technique. That said, I do consider this to be a temporary measure while the software is maturing to the point that I can get it accepted into the mainstream distros and build proper win/mac packages. That would be better for everyone, both from a usability and security standpoint. We are a very small team (usually just me) and these things take time.
- subway 14y ago
  Why wait on it to be accepted by the distros? What is stopping you from setting up a small Yum/Apt repo and publishing your GPG key?
  - HerraBRE 14y ago
    You mean like this? :-) https://pagekite.net/wiki/Howto/GNULinux/DebianPackage/ https://pagekite.net/wiki/Howto/GNULinux/DebianPackage/ https://pagekite.net/wiki/Howto/GNULinux/RpmPackage/ https://pagekite.net/wiki/Howto/GNULinux/RpmPackage/ ... this works and is the most conveninient way to use PageKite if you are treating it as part of the OS (so always on, exposing local servers). However, in the context of security and trust, you really should think thrice before installing 3rd party repos like mine - once you have added my repo to your OS, I can upgrade any package on your computer with whatever malicious content I want. So folks who don't trust me and my curl-bash hack really shouldn't trust this sort of solution either. This is why getting third parties to build, package and sign my software and getting into the public repos is the "correct" solution, but doing so didn't make sense while I was rapidly iterating. Things are starting to stabalize now, so I will probably be revisiting this very soon.