Since originally raising this issue with dkg (leading to this email
thread), I've only followed along from a bit of a distance. But it does
look like there's been some good progress: there's now a commit that
fills the pipe up to the OS's maximum pipe size, and then falls back to
the old (buggy, vulnerable, scary) behavior. Seems like there are several
problems with this approach:
- Determining the maximum pipe size at build time doesn't make sense
for systems where such a thing is actually determined (and adjustable)
at runtime.
- The security of this language construct is now OS and runtime-
configuration dependent. That means it's not that reliable, and so
we're basically back at advising square one: "don't use herestrings".
- If user-supplied input is used in a herestring, the user now controls
whether the secure path or the insecure path is used.
A real solution for this issue involves getting rid of the temporary file
all together. Since we're talking about a bash string, it's already in
memory. Why not just fork() if the write() will block? A simple way would be
to always fork(). A fancy way would be to set NONBLOCK mode, see if it
returns EAGAIN, and only fork() if the write would block. Either way seem
basically fine, with the critical part being that the temporary file is
totally gone from the equation.
Thoughts on this?
Thanks,
Jason
