On 24 Apr 2020, at 2:18, Rob Petrovec wrote:
I get a 1 second time for the first run and then a much quicker time
for the second. I did some sampling and the longer time due to is
Apple’s check for malware on first run of a process. This is a
known, documented and advertised behavior.
I would be very interested in documentation about what low-level APIs
(like execve) do malware checks (network access), under which conditions
they are performed, what servers are contacted, and what sort of caching
of good/bad results are done.
Is any of that documented?
There is also blacklisting going on: I can get an executable locally
blacklisted which will cause it to terminate instantly when executed.
This seems to be about some run-time code signature validation, and when
it happens, it appears to be the inode that gets blacklisted until next
reboot, but more info about this would be nice.
[…] So I don’t think this test is analogous to your initial issue
of a delay opening a file every time.
I said I get a similar delay the first time my app obtains URL
properties¹ for ~/Desktop, ~/Documents, and, ~/Downloads, and I
included sample code for this issue.
The actual delay appears to be in getxattr() which communicates with
sandboxd, and the delay disappears when disabling WiFi, hence why it
appears to also be a “phone home” issue like execve() above. But
where execve() only does it on “first launch”, this check seems to
be performed on first call after each new launch (for each different
“protected” file path).
Perhaps you would be willing to add this sample code to a GUI
application and see if you can reproduce? I re-attached it below, and
have the result written to /tmp/duration.txt so you don’t have to
fiddle with capturing log output.
Please note, it should be stand-alone GUI app launched from Finder, as
the delay does not (always) happen when launched from the terminal.
¹ I later said I have seen many delays on my system since upgrading to
macOS 10.15: But so far, I have only tracked down reproducible issues
with execve() and getxattr(), but those do not explain all my delays, so
there might be more low-level API that does “phone home”, I’m
still in the data collection phase.
----------8<----------
void test ()
{
NSTimeInterval startTime = NSDate.timeIntervalSinceReferenceDate;
NSArray<NSURL*>* urls = @[
[NSFileManager.defaultManager URLForDirectory:NSDesktopDirectory
inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil],
[NSFileManager.defaultManager URLForDirectory:NSDocumentDirectory
inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil],
[NSFileManager.defaultManager
URLForDirectory:NSDownloadsDirectory inDomain:NSUserDomainMask
appropriateForURL:nil create:NO error:nil],
];
NSString* localizedName;
for(NSURL* url in urls)
[url getResourceValue:&localizedName forKey:NSURLLocalizedNameKey
error:nil];
NSString* duration = [NSString stringWithFormat:@"Duration %.03f",
NSDate.timeIntervalSinceReferenceDate - startTime];
[duration writeToFile:@"/tmp/duration.txt" atomically:NO
encoding:NSUTF8StringEncoding error:nil];
}
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
