4 ms·

Ninety days. "Text as a cross-application data transfer format" and the Unix Philosophy of "chains of small programs that each do a single thing well" are what

Ninety days. "Text as a cross-application data transfer format" and the Unix Philosophy of "chains of small programs that each do a single thing well" are what lead to exploits like these. I don't know what the proper system design is, but it isn't these two things. Disagree all you like.

__david__ 6y ago
I disagree. This bug is about trying to embed control commands into an arbitrary non-structured data stream. This is a bad idea, no matter if it's text or binary. The proper way to do this would be like the report says: open a separate channel from control commands. This is just like any other injection attack and not related to the unix philosophy.
- naikrovek 6y ago
  It's the "non-structured" part of what you said that I tried, and failed, to point out with my comment.
  - pushrax 6y ago
    You don't need structure for secure control though, as long as the control channel is isolated. It's easier to make an insecure program when dealing with loosely described text streams, but it's by no means inevitable.
  - saagarjha 6y ago
    Doesn't have to be text.
hn_throwaway_99 6y ago
That's absolutely not what leads to exploits like these. What leads to exploits like these is "Interpreting output from untrusted code (i.e. output from arbitrary commands) in a manner which allows execution of protected commands (i.e. setting env vars)". Which is like the primary reason for most security vulnerabilities.
- jradd 6y ago
  good point. i think 'getting env vars' is the bigger issue here.
CodesInChaos 6y ago
I think switching text for a structured format is the solution. I'd go for some encoding of s-expressions, since it's the simplest format that supports reliable splitting into atoms and nesting.