4 ms·

There was no argument here, only a question. And it's a fair question to ask for the purposes of discussion. You're right, piping to sh is definitely a risk, a

There was no argument here, only a question. And it's a fair question to ask for the purposes of discussion. You're right, piping to sh is definitely a risk, and we should do better as a community, and not make users normalized to piping to sh.

godelski 3y ago
It appeared as a rhetorical question used to rebut the claim. Maybe I misinterpreted it. Fair. But that is a possible interpretation. But as you can see elsewhere, we shouldn't pipe streams into anything. It's just not hard to avoid this. A few extra characters and you're good to go. Let's take rust for example. Users are copy pasting anyways They give curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh But why not curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > /tmp/rust_install.sh && sh /tmp/rust_install.sh For user experience, it is till a one liner, but it is infinitely better. Still has some risks, but a lot less. (at least rust does wrap the install so you don't run the risk of partial line execution) And it gives the user a way to verify that the file was correct if they provide a checksum. There's just no good reason to not do this. We especially shouldn't be teaching noobies to pipe streams into any command. Let's be real, most people don't know linux well, even if they use linux.
- rezonant 3y ago
  > But as you can see elsewhere, we shouldn't pipe streams into anything. Firstly, I'll assume you mean untrusted streams since if you didn't mean that, we might as well throw out UNIX entirely. Even given that caveat though, I disagree. Downloading an image and then converting that image into another format is not a case where there's a material improvement in security when making temporary files instead of using pipes. I'd argue in some cases it may have the opposite effect. It's indicative of the lack of rationale on this more general case that you selected an example where the piping is into sh here. I agree with all of your points about piping into sh, just not that we can turn that into a general principal. It's OK if we have different best practices between these two cases. This kind of advice taken by a laymen or junior dev can cause problems, because the second you put the file on disk there's a risk you won't clean up that content, which for an automated system will ultimately bring it down when the disk fills up. In addition, if the information downloaded is sensitive, you are creating a security problem if you are intentionally writing it on disk even if you do clean it up later, as filesystem data remains persistent after unlink.

godelski 3y ago

It appeared as a rhetorical question used to rebut the claim. Maybe I misinterpreted it. Fair. But that is a possible interpretation. But as you can see elsewhere, we shouldn't pipe streams into anything. It's just not hard to avoid this. A few extra characters and you're good to go. Let's take rust for example. Users are copy pasting anyways They give curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh But why not curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > /tmp/rust_install.sh && sh /tmp/rust_install.sh For user experience, it is till a one liner, but it is infinitely better. Still has some risks, but a lot less. (at least rust does wrap the install so you don't run the risk of partial line execution) And it gives the user a way to verify that the file was correct if they provide a checksum. There's just no good reason to not do this. We especially shouldn't be teaching noobies to pipe streams into any command. Let's be real, most people don't know linux well, even if they use linux.

rezonant 3y ago
> But as you can see elsewhere, we shouldn't pipe streams into anything. Firstly, I'll assume you mean untrusted streams since if you didn't mean that, we might as well throw out UNIX entirely. Even given that caveat though, I disagree. Downloading an image and then converting that image into another format is not a case where there's a material improvement in security when making temporary files instead of using pipes. I'd argue in some cases it may have the opposite effect. It's indicative of the lack of rationale on this more general case that you selected an example where the piping is into sh here. I agree with all of your points about piping into sh, just not that we can turn that into a general principal. It's OK if we have different best practices between these two cases. This kind of advice taken by a laymen or junior dev can cause problems, because the second you put the file on disk there's a risk you won't clean up that content, which for an automated system will ultimately bring it down when the disk fills up. In addition, if the information downloaded is sensitive, you are creating a security problem if you are intentionally writing it on disk even if you do clean it up later, as filesystem data remains persistent after unlink.