It's not really my question. In the past, following or not following symbolic links could be controlled by the developer building the package (by using the modern version of the IFPkgFlagFollowLinks flag). Now, it looks like that the options that the developer set is not taken anymore into account by the installation mechanism of recent macOS versions. This looks like both a regression bug and a security issue. But at the same time since the package format has never been officially documented (contrary to the distribution XML file or Installer JS (with its own bugs: e.g. FB20448952)), it's difficult to file a bug report that states that an undocumented option that has been working for many years is not working anymore and is a regression. But the behavior of always following symbolic links could be a security issue depending on where the items of the payload are to be installed.

Looks like it's worth creating a feedback assistant ticket.

How are you determining they're "invalid"? […] I suspect those are zombie processes Yes, these look like to be zombie processes (listed as in ps output). They seem to be grouped after "pid" 0. But OK, I will assume that the order is not guaranteed. They were seen as invalid as they didn't appear in Activity Monitor.app. It can return a PID that's no longer valid (the process was terminated immediately after the call was made). PIDs can be "missing" from the list (because they were created immediately after the call was made). Yes, this is fair as this is just a snapshot. That's also why I thought that there could be no guarantees that the number of entries returned by the API was the exact number of entries instead of just a maximum number of entries in the populated list (i.e. entries after "pid" 0 were just random values).

Well, the best guide is probably our own code with "top" being the most straightforward example. The top project would have been an interesting pointer if the source code for top included a call to proc_listallpids. Which is not the case. No, that's not what's going on. Both of those pids will always be returned by proc_listallpids because they're "special" within the system. You probably have misread what I wrote. I'm not telling that they won't be returned. As I mentioned, the proc_listallpids API returns a list of the existing pids in a decreasing order. So in theory, the last pid should be 0 or 1 depending on whether you consider that the kernel is a process. But in practice, the API can end up listing pids after pid 0. And it's not just padding. Those are the pids that are invalid. Sorry for the time you spent explaining why launchd is special, I already knew about all this stuff.

OK, I will file tickets. At least the IBAction one is still happening in Xcode 26.2.

Thanks. I will file multiple feedback assistant tickets as getting documentations and fixing the issues seem to be 2 different topics.

API != command line tool. Not a fan of using command line tools either. I have already a radar/feedback assistant ticket about this issue: 21381323

This issue is related to notarization assessment not being automatically done by the OS. [Q] Are there public APIs to assess notarization? There are private APIs (visible in the security open source code of the security library) but there does not seem to be public APIs.

I don't think the problem is coming from the macOS instance itself as the problem does not occur when the extension is updated using an installation package. The problem only happens when replacing the system extension and its wrapper .app using basic NSFileManager APIs. I diffed the 2 cases and there are no differences. Same files, same contents. And anyway spctl and codesign are happy. I tried different macOS versions in VMs (14, 15). Same result. What I'm also observing is that after updating the system extension using an installation package, just using the NSFileManager APIs is going to work fine when reverting to any version that has been previous installed via an installation package or updating to version that has been previously updated via an installation package.

It looks like that the issue is not reproducible in the 15.6 RC.

It can be reproduced in macOS 26 beta 1 and beta 2.

Feedback ID: 18731867

I don't have logs, only a memgraph, so I can't say whether there were 2 starts logged. The 2 instances are referenced by a collection object (owned by a different class instance). The data filter instance adds itself to the collection from the startFilterWithCompletionHandler: method and removed itself from the collection from the stopFilterWithReason: method. So the most probable hypothesis is that the stopFilterWithReason: was not called. Which would be more a bug in the NetworkExtension framework. I haven't been able to reproduce this case so far (like by disabling/enabling the Network filter from the System Settings).

It is a System Extension with only one data filter.

A sub folder of /Applications, yes.