I since found that /Library/Filesystems is user-writable (but requires root). In order to expose mount_<filesystem> to autofs, the following directory can be added: /Library/Filesystems/<filesystem>.fs └── Contents └── Resources └── mount_<filesystem>

Are these agents owned by Apple or by some other 3rd party?

FWIW I have file the bug via Feedback Assistant: FB11958573

Interesting. I suspect that’s because the Applications folder is only writable by admin But the user that's launching the app is an admin (me). Anyway, why does writability of /Applications or even /Applications/.app affects the behavior? Isn't the actual value of the quarantine attribute stored in a db somewhere else, per-user?

Hmm, why would writability of /Application have any effect though? The installation process run via Homebrew by a non-admin user[1], in a nutshell, uses a shell script that downloads app's archive, unpacks it and then uses sudo[2] to move it to /Applications. As a result, I end up with a brew:brew owned app in the /Applications directory with the quarantine attribute assigned and set. When I run the app via my main admin user account and agree to the dialog (which is shown exactly once, on the first run only) I expect the quarantine attribute to get cleared for my main admin user. The login item is added to the gui/ domain so I expect launchd to consult the appropriate database when checking whether the login item is allowed to run. The way I understand gatekeeper process (root daemons) and quarantine attribute (values are per-user[3]), neither writability of /Applications nor /Applications/Maccy.app should have any effect. [1]: $ sudo -u brew id uid=801(brew) gid=801(brew) groups=801(brew),101(access_bpf),12(everyone),20(staff),61(localaccounts),701(com.apple.sharepoint.group.1),100(_lpoperator) [2]: On my machine, sudoers is set up such that plain sudo uses my main admin user account and not root via the runas_default and runaspw settings. [3]: If you run the app and agree to the warning then quit it and chown it someone else, it will display the warning again on the next run. So I'm not sure whether the actual quarantine value is preserved per file owner, per process owner or a combination of both.

Okay, I seem to get to the bottom of this. One detail that I missed is that I run homebrew installation process as a non-admin user and group: $ dscl . -read /Users/brew dsAttrTypeNative:IsHidden: 1 PrimaryGroupID: 801 RealName: Homebrew RecordName: brew RecordType: dsRecTypeStandard:Users UniqueID: 801 UserShell: /usr/bin/false $ dscl . -read /Groups/brew GroupMembership: brew PrimaryGroupID: 801 RealName: Homebrew RecordName: brew RecordType: dsRecTypeStandard:Groups When Homebrew installs the app, I end up with a bundle owned by brew:brew. Launching the app with login user will display the warning only once, but the quarantine attribute will remain with unchanged value regardless of how many times I restart it. However, if I chown the app to the login user before the launch, I will get the warning again (even if I already got one when it was owned by other user) but this time attribute's value will get cleared. Do you think I should file a bug?

It uses the older SMLoginItemSetEnabled.

FWIW, proposals on iPhone with iOS 15.2.1: Phase 1: ID:ENCR/PRF/D-H IKE:AES-CBC-256/SHA2-256/MODP-2048 IKE:AES-CBC-256/SHA1/MODP-2048 IKE:AES-CBC-256/MD5/MODP-2048 IKE:AES-CBC-256/SHA2-512/MODP-2048 IKE:AES-CBC-256/SHA1/MODP-1024 IKE:AES-CBC-256/MD5/MODP-1024 IKE:AES-CBC-128/SHA1/MODP-1024 IKE:AES-CBC-128/MD5/MODP-1024 IKE:3DES-CBC/SHA1/MODP-1024 IKE:3DES-CBC/MD5/MODP-1024 IKE:DES-CBC/SHA1/MODP-1024 IKE:DES-CBC/MD5/MODP-1024 Phase 2: ID:ENCR/PRF IKE:AES-CBC-256/SHA2-256 IKE:AES-CBC-256/SHA1 IKE:AES-CBC-256/MD5 IKE:AES-CBC-128/SHA2-256 IKE:AES-CBC-128/SHA1 IKE:AES-CBC-128/MD5 IKE:3DES/SHA2-256 IKE:3DES/SHA1 IKE:3DES/MD5

The SO_NET_SERVICE_TYPE option and its siblings StreamNetworkServiceType, NSStreamNetworkServiceType, kCFStreamNetworkServiceType configure Layer 1/2 QoS priority. In case of Wi-Fi they set 802.11 User Priority (UP). Whether it actually gets set in the actually transmitted frame depends on whether the OS trusts your application. AFAIK for iOS/iPadOS this feature has to be enabled via MDM for a generic app. Apps made by Apple and some other vendors, like Cisco, are trusted without this permissions. What happens next depends on your network equipment (routers, switches, APs etc) and its configuration. Some may translate received 802.11 UP into DSCP according to some mapping (either via RFC8325 or by whatever policy conceived by network admins). Additionally, you can set Layer 3 QoS via the DSCP (RFC 2474) field of an IP frame either by setting IP_TOS directly or setting the IP_HDRINCL socket option and supplying custom IP header. Don't get confused by option's name (TOS): it's exactly the same bits of the IP header. Treat it as DSCP. See the '-K' and '-z' options in ping.c from Apple opensource for usage examples.

@kaunteya that is not correct. Internally it may be either a NSLayoutGuide or an NSView. The Any? "hack" is necessary since there is no protocol to express *anchor properties. But in practice it will be an NSLayoutGuide most of the time unless you customize window's content view or play with its view hierarchy.

Quinn,My apologies by I seem to miss something obvious here. In this reply you suggested two paths:1. Use a private API to acquire the audit token of an XPC connection2. Use PID but rely on that 2nd and forth messages are guaranteed to come from the same connectionWhile [1] is quite clear I'm completly puzzled by [2].Which of the following do you suggest:1. Run peer validation pased on code object created from a PID associated with the connection upon receiving the first message, then, if successful, mark that connection authenticated and perform priviliged work starting with the 2nd message2. Same as [1] but re-validate the peer for each message3. Something else---The scenario I have in mind is:1. Malicious process starts, sends 2 messages2. The system does whaterver it does, processes the messages and enques them for delivery to user's code3. Malicious process through other means (e.g. timing?) figures out that its messages were enqued for delivery and initiates wrapping4. Legitimate process takes its places5. Enqueued messages finally reach user's code. User acquires PID, gets code object of the Legitimate process and responds to the messages. Since both message are already enqueued user has no chance (aside from using private API to get auditToken) to recognize malicious intent.To avoid the attack, as I understand, the OS must not bulk process messages. Instead it should process them one by one, only picking the next message after user's code is done with the previous one.In the scenario above it would force the peer to be around up until the moment the 2nd message was passed to user's code. Thus preventing the wrap.Please guide me!

As a workaround I explicitly set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to NO in the main app and added the following Run Script phase:/usr/bin/xcrun swift-stdlib-tool \--copy \--verbose \--sign ${EXPANDED_CODE_SIGN_IDENTITY} \--scan-folder ${TARGET_BUILD_DIR}/${CONTENTS_FOLDER_PATH} \--platform macosx \--toolchain ${DT_TOOLCHAIN_DIR} \--destination ${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH} \--strip-bitcode \--strip-bitcode-tool ${DT_TOOLCHAIN_DIR}/usr/bin/bitcode_stripwith a single output file:${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}/libswiftCore.dylib

I'm hitting, possibly, a related bug with Xcode 11.3.1: in my case swift libraries are not included. After checking the build log I found that CopySwiftLibs is executed with a bunch of --scan-executable and --scan-dir arguments. But this arguments miss the necessary path, in particular path to XPC services.I checked release notes for newer versions of Xcode but have not found that issue being listed. Is there a known workaround?

Answering my own question: `out` tells the compiler that current value of the retainable object pointer is of no importance to the receiver which allows to elide some retain / release calls. The usecase documented above is actually the only usecase in Apple Clang 11.0.0

While the OS ensures that the second message can only be sent by the same process that sent the first message, it alone is not enough for user's code in the XPC service.Thus it seems important for user's code in the XPC service to:1. When handling the first message capture process's identity (in terms of requirements, version, code signature etc) and avoid performing any priviliged actions. In other words let the first message be a handshake.2. When handling all consequent messages use the identity captured in [1] for permissions check before performing any priviliged actionsAt least it appears to be enough if permissions checks are run against code signature and backed-in data (such as requirements) which is also reflected by the signature.Is my understanding more-or-less in line with what you have suggested above?