rev-upgrade and checking for +universal dependencies (and build dependencies)

[Saagar Jha]

> On Jun 9, 2024, at 12:10, Clemens Lang <cal at macports.org> wrote:
> 
> On Sat, Jun 08, 2024 at 01:10:50PM +0200, René J.V. Bertin wrote:
>> On Saturday June 08 2024 09:46:34 Clemens Lang wrote:
>> 
>>> Using library preloading – which does not currently work against
>>> Apple's binaries on Apple Silicon Macs.
>> 
>> But those aren't installed through MacPorts. Does it matter here
>> whether SIP & family are enabled or not, btw?
> 
> With SIP disabled, one can add a kernel boot argument to allow user
> space to use Apple's ABI with pointer authentication, which would allow
> building a copy of tracelib that works on those binaries.
> 
> I'm not aware that anybody has successfully done that.

I have. I never chose to upstream it because I figured that nobody cared for that configuration, and it has the unfortunate quality that it cannot be done in a way that degrades gracefully when SIP is off. On systems where SIP is disabled, the loader will look for an arm64e slice or complain loudly. If you include such a slice and SIP is disabled it will be preferentially selected over an arm64 version by the fat binary matching algorithm, and immediately terminate the process upon load. So there’s no good answer here :(

> It doesn't matter whether those are installed through MacPorts. Builds
> use many of those binaries (e.g., the Shell, or clang), and trace mode
> doesn't work on those binaries, rendering it essentially useless.
> Additionally, attempting to inject those binaries causes the program to
> be killed by the kernel, i.e., things break.
> 
> 
>>> Tracelib only works on spawned subprocesses, not the MacPorts tclsh
>>> process itself, so in order for that to work, rev-upgrade would have
>>> to spawn a separate process, which it currently does not.
>> 
>> For this particular case that should be a trivial detail. The
>> rev-upgrade procedure does not itself spawn any helper processes at
>> the moment, correct?
> 
> Correct, but it's not really trivial, it would require a significant
> rewrite and a way to communicate the results across the process
> boundary.
> 
> 
>> The elegance and security of a single command that can be written to
>> handle all possible error situations. Plus you're not crippling any
>> functionality at all.
> 
> Sure, but if I weigh that against the effort to implement it, it's not
> worth it in my book.
> 
> 
>> BTW, in terms of evaluation dependents of a shared library: would it
>> suffice to remove read and/or execute permissions from the file rather
>> than making the file disappear completely? If so it might already be
>> enough to do that for just the file owner, provided the rev-upgrade
>> scan is run as that user.  I suppose that files are normally owned by
>> root in a normal MP installation...
> 
> Many Unix operating systems, including macOS, do not actually care about
> file permissions when you are root:
> 
> :) root at cBookMax:/tmp# ls -lash test
> 8 ----------  1 root  wheel     4B Jun  9 21:09 test
> :) root at cBookMax:/tmp# cat test
> foo
> 
> -- 
> Clemens
>