Re: "here strings" and tmpfiles

[Jason A. Donenfeld]

Hi Chet,

On Wed, Apr 10, 2019 at 3:07 PM Chet Ramey <chet.ramey@case.edu> wrote:
> This is unnecessary hyperbole. The existing file-based mechanism works
> just fine. We're talking about what's essentially an optimization.
> [...]
> This doesn't make any sense.
> [...]
> There isn't an "insecure path."

I'm a bit late to the thread, so apologies if I came with some
presumptions about what we were discussing. I certainly didn't mean
any hyperbole. Rather, I have one very specific thing in mind: in some
security contexts, it's important that certain data doesn't hit the
disk but rather remains in memory. Talk all you want about how this
shouldn't be a real requirement, but actually, in certain contexts it
very much is. Now, it might be the case that bash really isn't the
right tool for that kind of thing, and I shouldn't use bash for tasks
with security requirements as such. But I sort of love bash, and have
written a lot of it, and I want it to be suitable for this. So from my
perspective, we're not talking about a mere optimization, but instead
something that either makes herestrings available for usage in this
context, or keeps them unavailable in this context.

I hope that can shed light on the motivation a bit. Pass got hit by
this a bit ago:
https://git.zx2c4.com/password-store/commit/?id=367efa5846492e1b0898aad8a2c26ce94163ba24

Anyway, the more interesting thing is discussing what a proper fix
would be. Do you see anything conceptually wrong with the NONBLOCK
approach I suggested? In theory, would that work? Another thing I was
curious about is - what about internally treating "x <<y" as "echo y |
x"? Are these somehow not quite equivalent because x is in a subshell
in one but not the other, or something like that? And if that's so,
would my NONBLOCK suggestion incur similar issues?

Jason