Hi Chet, On Wed, Apr 10, 2019 at 3:07 PM Chet Ramey <chet.ra...@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
