Darwin Version

[Clemens Lang]

Hi Jeremy,

----- On 3 Oct, 2015, at 10:56, Jeremy Huddleston Sequoia jeremyhu at apple.com wrote:

>> In theory, we have a solution for this problem: trace mode hides anything from
>> a port's build system that doesn't come with the system and is not in the list
>> of dependencies, so *in theory* we could replace migration with
>>  sudo port -t upgrade outdated,
>> and in fact, I successfully tested this during the last OS upgrade. With the
>> upgrade to El Capitan, though, Apple's System Integrity Protection actually
>> breaks trace mode (Yay!), so this not an option, leading us to recommend the
>> migration procedure.
> 
> How does SIP break it?  Do you have a radar or MP ticket?  I'm curious to
> followup on that.

DYLD_ variables are stripped from the environment when executing binaries under
SIP. That no longer allows us to preload our tracing library into lots and lots
of tools we use, such as /bin/sh, /usr/bin/python, /usr/bin/make, /usr/bin/clang,
etc.

My impression is that this was a deliberate security decision to make sure the
binary you are executing is actually the one protected by SIP and the exact
version Apple provided. Please correct me if this assumption is wrong.

For now, I think trace mode can be modified to work around this limitation by
keeping a shadow copy of all binaries under SIP it wants to execute; since we
wrap posix_spawn and execve, we can determine whether the executed binary has
SIP enabled, copy it if that's the case, and run the copy instead,
circumventing the security measures.

Btw, what I would actually consider a bug is that running /usr/bin/env (or
printenv) now no longer show any DYLD_* variables that may be set in your
environment. Previously we would ask users to run env | grep DYLD_ to check
for environment variables if they had trouble executing binaries installed
using MacPorts. I guess we'll go with (set -o posix; set) | grep DYLD_ now,
even though that's not the same.

-- 
Clemens Lang