The author writes that this kind of ad-hoc breakage of system interfaces is a "good thing in general" but it absolutely is not. I've dealt with this kind of lazy, reactionary response to security extensively. It's pernicious and becomes incredibly destructive at scale.<p>Interfaces must be simple and consistent. Inconsistencies make systems dramatically more difficult to use -- but it's notoriously hard to measure the cost of system complexity and the countervailing pitch to confound simplicity is very straightforward: "Bad guys did this thing. This is a rarely used thing. Let's break this thing."<p>As this blog illustrates, it is now prohibitively difficult to explain or predict how environment propagates in OSX. There is a dramatic increase in the likelihood of bugs. It would be better to simply delete the functionality of DYLD_LIBRARY_PATH from the dynamic linker. Of course, we can't do that because DYLD_LIBRARY_PATH exists for an important reason -- but that important reason is also why DYLD_LIBRARY_PATH's functionality should be protected and not capriciously broken in this fashion.<p>This kind of approach to security will always result in fragile, buggy systems in the long term. It will also undermine developer comfort, ultimately reducing the number of people willing to develop software for a platform (one straw among many, but they add up and eventually there's a final straw)<p>Are attackers really going to be deterred by destroying the convenience of setting environments in shells? Of course not. Figuring out how to set environment without using Apple's broken userland is a trivial task. So what's the point?