Why is Macports doing this?

[Bill Cole]

On 29 Oct 2020, at 8:41, bunk3m wrote:

> I've been using Little Snitch for some time and Macports for much 
> longer.
>
> In the past few months I started getting a notice that the user 
> macports is trying to run trustd.

Rather: the OS is running a trustd instance as the macports user.

Apple does not offer easily found documentation on why or when any 
particular user gets a trustd instance but if you look, you'll find at 
least a main daemon running as root and one agent instance for each 
logged in user, and unless you've disabled related facilities, one agent 
instance each for _locationd and _spotlight. It appears that these 
agents are started by the daemon whenever a process running as the 
particular user attempts to validate a certificate using OS facilities. 
If you look at all of the processes on a running Mac, you will find a 
number of similar cases: secd, lsd, cprefsd, distnoted, etc.

> Why would macports be running a process every morning to connect to 
> Apple?  I thought Macports only ran when you invoked it from the 
> command line.

The 'port' process only runs when invoked and for any modifications of 
the system it must be run as 'root' via sudo. It uses the 'macports' 
user id for some tasks that should not be run as root or the logged-in 
human user. When that is done and certain OS facilities are used, the 
system spawns agent instances of relevant daemons like trustd so that 
the processes running as macports can talk to the master daemons in a 
safe and structured way specific to the context of the macports user. 
Those agent instances don't exit automatically because once used, they 
are extremely cheap to leave running: a few KB of memory and almost no 
CPU or I/O until used again. The "almost" in the case of trustd is that 
the agent instances apparently do some housekeeping on a daily basis 
that includes contacting the Apple OCSP (Online Certificate Status 
Protocol) server. My guess is that this is cache maintenance of some 
sort.

There is no feasible way for MacPorts to prevent this behavior. Short of 
doing certificate validation internally, which would risk diverging from 
how the OS does it via trustd, there is no way at all.

> I hope the screenshot will come through that shows the Little Snitch 
> notice.

It did. It shows a trustd process whose binary (/usr/libexec/trustd) is 
signed by Apple (and which is protected by SIP on modern systems) 
running *as* macports, NOT any part of MacPorts running. I'm a bit 
surprised that LS does not recognize this as something it should pass 
without alerting.

-- 
Bill Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire