Post not yet marked as solved
In our implementation of the DNSProxyProvider we are using the sourceAppSigningIdentifier obtained from the metadata of the FlowHandler to identify the origin of DNS queries being made by that FlowHandler. For most cases we are receiving useful info (i.e the originating app), but there is one specific case related to download tasks for a background NSURLSession where the info is empty.Now I do realise that both sourceAppSigningIdentifier and sourceAppUniqueIdentifier are documented as 'may be empty in cases where the flow originates from a system process', but I am not sure if in my case if this is intentional, a bug or an oversight.The case where no info is provided is when a background download initiates the flow when the originating app is no longer running. i.e The app might be doing a discretionary download or one with an earliestBeginDate set to the future. If the originating app initiates a task, but stays running while the flow gets created (whether frontmost app or not) then sourceAppSigningIdentifier contains the correct information.To me this seems like its not intentional. My best guess for how such download tasks are accomplished is that they are immediately handed off to some system process to deal with, along with info about the calling app. So that information should still be available to this system process regardless of whether the app has been jetsamed in the meantime. And as such the NEFlowMetaData should be correctly populated.As things currently stand, we are not able to determin the originating app in these cases and are unable to inform the user of why such a request might have been blocked. Also, for some apps we want to block all DNS requests, but with this behaviour there is a loophole that could be exploited by the app to bypass such a block.
Post not yet marked as solved
Instruments 9.2 has the option to choose to profile a LunachDaemon by selecting the relevant launchd plist file. Then when you start to record it shows an alert with:Waiting for /Library/LaunchDaemons/com.mydaemon.plistPlease take appropriate action to initiate the launch of '/Library/LaunchDaemons/com.mydaemon.plist.'With a Cancel button.But it never notices tha daemon launching, even when I do take appropriate action. In my case via:launchctl bootstrap system "/Library/LaunchDaemons/com.mydaemon.plist"launchctl kickstart system/com.mydaemonThe daemon launches but Instruments does nothing.Any ideas?
I'm just starting out trying to use os_activity and have hit an annoyance. Attempting to add a breakpoint to any line of code with os_activity_initiate block does not work as expected. Instead it seems to break after the call to os_activity_initiate.E.g Consider this:- (IBAction)doActivity:(id)sender
{
os_activity_initiate("Test Activity", OS_ACTIVITY_FLAG_DEFAULT, ^{
NSLog(@"Doing activity");
NSBeep(); // <<-- Try to add a preakpoint here
NSLog(@"Finished activity");
});
}Try to put a breakpoint at the NSBeep() line. By the time it fires, both NSLog calls will have already been done.Only solution I can find is to wrap all such code inside os_activity_initiate blocks into a local block (or other function) but that's no fun.BTW - Xcode 9.2 Debug configuration and macOS 10.13.2
Post not yet marked as solved
So I'm trying to update a bunch of build scripts for our Mac Apps to no longer be tied to using Xcode 8.2.1 and the obsolete -exportFormat PKG arguments.and use the modern -exportOptionsPlist options instead.According to xcodebuild -h: method : String Describes how Xcode should export the archive. Available options: app-store, ad-hoc, package, enterprise, development, developer-id, and mac-application. The list of options varies based on the type of archive. Defaults to development.i.e previously I had something like thisxcodebuild -exportArchive -exportFormat PKG -archivePath MyApp.xcarchive -exportPath "Install MyApp.pkg" -exportSigningIdentity "MySigingingId"I've created an export options plist like this:<plist version="1.0"><dict> <key>compileBitcode</key> <false/> <key>method</key> <string>package</string></dict></plist>and am now calling:xcodebuild -exportArchive -archivePath MyApp.xcarchive -exportPath "Install MyApp.pkg" -exportOptionsPlist ExportPackage.plistBut that gives the following error:exportArchive: exportOptionsPlist error for key 'method': expected one of {app-store, developer-id, development, mac-application}, but found packageSo I am guessing exporting packages from the xcodebuild -exportArchive is not really supported anymore and I'll just have to convert all my scripts to export the app first and then run pkgbuild to create the installer. Am I correct? If so I'll raise a bug report that xcodebuild -h is wrong in saying 'package' is allowed for the 'method' property.
Post not yet marked as solved
Since updating from Xcode 8.x to 9.1, I get the following warning when linking my kext:object file (/Applications/Xcode_9.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib/libkmod.a(c_start.o)) was built for newer OSX version (10.13) than being linked (10.12)This seems to be because my deployment target is set to 10.12 but I'm now using the 10.13 SDK with Xcode 9.Should I worry about this warning? If not, is there any way to silence it without silencing all warnings from the linker.If I should worry about it (i.e it might cause subtle issues), what should I do about it? Try and dig out the libkmod.a file from the older 10.12 SDK and force that to be used?
Post not yet marked as solved
According to https://developer.apple.com/documentation/os/logging?language=objc, the following value types have built-in formatters in os_log:time_t, timeval, timespec, errno, iec-bytes, bitrate, iec-bitrate and uuid_t.But according to https://developer.apple.com/videos/play/wwdc2016/721 (28:42)there is also support for sockaddr, in_addr and in6_addr via %{network:sockaddr}.*P, %{network:in_addr}d and %{network:in6_addr}.16P.Are these officially supported so I can start using them, and if so, are there any other such 'undocumented' types that are also officially supported.
Post not yet marked as solved
usr/include/dispatch/dispatch.h has the following:#if !defined(HAVE_UNISTD_H) || HAVE_UNISTD_H#include <unistd.h>#endifBut any code that tries to bring in dispatch.h without having defined HAVE_UNISTD_H gets an error:/Applications/Xcode_9.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/dispatch/dispatch.h:38:45: error: expected value in expression
#if !defined(HAVE_UNISTD_H) || HAVE_UNISTD_H
^Which makes sense as I think that #if is syntacticaly wrong in the case when HAVE_UNISTD_H is undefined.And reading it it makes no sense anyway. Given what it seems to be doing its saying not to include unistd.h only in the case where HAVE_UNISTD_H is defined but is 0.
Wellington.