4 ms·

I don't see any rational basis for this. If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one l

by chc 13y ago

I don't see any rational basis for this. If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three. And if you do want to vet the code, you know what to do. Practically no installation instructions include a "vet the code" step, so you aren't losing anything here. The lack of TLS is worrisome, but that's not so much "becoming a thing" as it is "a bad thing we're just finally starting to get rid of."

rsync 13y ago
Although this isn't new, it should make you throw up in your mouth a little bit. Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages. I suppose this is tilting at windmills, though.
- chc 13y ago
  > Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages. Yes, and you still can do that. But the standard installation instructions almost never include it. For example, nginx's build instructions boil down to "run configure, possibly with some flags, and then run make and/or make install". That includes the exact same vulnerability you complain of here — it never tells you to checksum anything. This is true for essentially all the software I've ever downloaded. So again, still not "becoming a thing." The assumption is that if you're the sort of person who customarily checks code before they install it, you know how to inject that step.
eksith 13y ago
>"If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three." Nginx is included in the OpenBSD base system (as of 5.2) and it does get vetted.
- chc 13y ago
  I am not seeing the relevance.
  - eksith 13y ago
    Your assertion is that if we want to vet the code, there are steps to do that and no conventional installation includes these steps, correct? Well, getting the "trust us, this is easy" type installation instructions here isn't terribly comforting from a brand new project. That's the sort of thing I'd expect from a source I know. Not from this project that I didn't even know existed before this post. It's unrealistic to expect those who take security seriously to do so in the first place. Regardless of how often it's done elsewhere. OTOH, there's a well known and trusted software distributor that does the vetting for you, which this project doesn't have, and I'd much rather do the "vetting-skipped install" if you will for something they distribute instead.
    - chc 13y ago
      That's all true, but I don't see what it adds to the conversation. It's just a plug for nginx. "Conservative, security-conscious people like older projects with large, trusted organizations backing them" is something of a tautology.
      - eksith 13y ago
        This conversation started when you said you don't see any rational basis for the criticism of running wget/install as root when no vetting takes place on conventional installations. My post wasn't a plug for Nginx, but an imploring to know what you install. Since I can't know everything that's running on my system, I'd trust that from some place that actually does vetting. It doesn't need to be OpenBSD, but some competent source with an established record for security. That's not tautology. It's sane practice that I wish more people followed. The wget/shell install as root is presumptuous in the extreme for a young project with no history. In fact, many young projects, whose security we know nothing about, have similar installations and that's a bad precedent to set and continue.

by chc 13y ago

rsync 13y ago

Although this isn't new, it should make you throw up in your mouth a little bit. Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages. I suppose this is tilting at windmills, though.

chc 13y ago
> Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages. Yes, and you still can do that. But the standard installation instructions almost never include it. For example, nginx's build instructions boil down to "run configure, possibly with some flags, and then run make and/or make install". That includes the exact same vulnerability you complain of here — it never tells you to checksum anything. This is true for essentially all the software I've ever downloaded. So again, still not "becoming a thing." The assumption is that if you're the sort of person who customarily checks code before they install it, you know how to inject that step.

eksith 13y ago

>"If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three." Nginx is included in the OpenBSD base system (as of 5.2) and it does get vetted.

chc 13y ago
I am not seeing the relevance.
- eksith 13y ago
  Your assertion is that if we want to vet the code, there are steps to do that and no conventional installation includes these steps, correct? Well, getting the "trust us, this is easy" type installation instructions here isn't terribly comforting from a brand new project. That's the sort of thing I'd expect from a source I know. Not from this project that I didn't even know existed before this post. It's unrealistic to expect those who take security seriously to do so in the first place. Regardless of how often it's done elsewhere. OTOH, there's a well known and trusted software distributor that does the vetting for you, which this project doesn't have, and I'd much rather do the "vetting-skipped install" if you will for something they distribute instead.
  - chc 13y ago
    That's all true, but I don't see what it adds to the conversation. It's just a plug for nginx. "Conservative, security-conscious people like older projects with large, trusted organizations backing them" is something of a tautology.
    - eksith 13y ago
      This conversation started when you said you don't see any rational basis for the criticism of running wget/install as root when no vetting takes place on conventional installations. My post wasn't a plug for Nginx, but an imploring to know what you install. Since I can't know everything that's running on my system, I'd trust that from some place that actually does vetting. It doesn't need to be OpenBSD, but some competent source with an established record for security. That's not tautology. It's sane practice that I wish more people followed. The wget/shell install as root is presumptuous in the extreme for a young project with no history. In fact, many young projects, whose security we know nothing about, have similar installations and that's a bad precedent to set and continue.