Why is Macports doing this?
macportsusers-20171215 at billmail.scconsult.com
Thu Oct 29 14:28:27 UTC 2020
On 29 Oct 2020, at 8:41, bunk3m wrote:
> I've been using Little Snitch for some time and Macports for much
> 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
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
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
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
More information about the macports-users