User Profile

Is it true that signing should always over-write any existing code-signing?I ask because I've had a recent case where this was done in SD Notary. The signing (of a framework) succeeded and notarization succeeded, although the app then failed when it tried to load the framework. I checked the logFileURL and there was an issue saying the framework was not signed.I repeated the exercise, this time starting with an un-signed version of the framework, and all went well. (I have no idea how the previous version was signed -- it was from a user).

Is there any reason why notarization shouldn't be performed using the copy of `altools` in Transporter.app rather than the one in Xcode? It says it's version 1.1, which is the same as was in Xcode 10.3, although the file is smaller. A quick test here shows it works OK.(I'm particularly thinking of people signing AppleScript applets, who otherwise have no reason to download the many gigs of Xcode.

I distribute several AppleScript script libraries. Some of them are in .scptd bundle form and encapsulate Objective-C frameworks -- the AppleScript part is essentially a wrapper, providing terminology and some type coercion. This is basically the technique suggested as a replacement for scripting additions.As of macOS 10.14, these no longer work with Script Editor because it can't load third-party frameworks, but they still work fine in Script Debugger, and in scripts run as standard AppleScript applets or as scripts from run within other applications.The documents and their contained frameworks have always been distributed unsigned. Most scripters don't have developer accounts, and don't distribute their scripts widely. Some end up including the libraries in their own AppleScript applets, which they may distribute unsigned.I'm now looking for advice on the correct way to deal with these libraries in macOS 10.15. As it stands, if someone downloads and installs one, they get an error if they try to use it.The simplest solution form my point of view is to advise users to remove the quarantine attribute from them after they download them, which solves the problem, but for obvious reasons I'd rather not. So I'm looking for advice on a secure approach.As I said, most users don't have developer accounts and therefore don't sign their code. Where they distribute such scripts, the user can still run them via control-open. But if I were to sign the libraries, I suspect they would lose this ability. (Control-open works where apps have no signature, but not where there's a problem with a signature, and having an app part-signed would seem likely to trigger the latter.)Complicating matters is that Xcode doesn't seem to want to produce unsigned frameworks anymore anyway. And there's the issue of just how I sign them anyway, if I should.I'd appreciate any guidance/suggestions.

I have some code that perfoms a deep enumeration of system frameworks (it collects .bridgesupport files). It seems that `enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:` behaves differently in such a case under 19A512f, skipping directory contents. I have to use `subpathsAtPath:` instead.Here's some code that demonstrates the problem: NSFileManager *fileManager = [NSFileManager defaultManager]; NSURL *fwURL = [NSURL fileURLWithPath:@"/System/Library/Frameworks/Foundation.framework"]; // fwURL = [[fileManager URLsForDirectory:NSDesktopDirectory inDomains:NSUserDomainMask] firstObject]; //This returns all subpaths OK: NSArray *temp = [fileManager subpathsAtPath:fwURL.path]; NSLog(@"There are %lu subpaths at %@\n", (unsigned long)temp.count, fwURL.path); NSDirectoryEnumerator *enumerator = [fileManager enumeratorAtURL:fwURL includingPropertiesForKeys:@[NSURLIsDirectoryKey] options:0 errorHandler:NULL]; NSArray *urls = [enumerator allObjects]; NSLog(@"There are %lu urls at %@", (unsigned long)urls.count, fwURL.path); if (urls.count < temp.count) { NSLog(@"URLs found: %@\n", [[urls valueForKey:@"path"] componentsJoinedByString:@"\n"]); }If you uncomment the line that modifies `fwURL`, you will see the code works fine for the Desktop directory. This suggests it might be somehow either security related (and undocumented as far as I can see), or a problem with URLs linking to the system drive. Either way, it seems like a serious bug/change in behavior.I logged a bug (FB 6800366). The response I've received is:our engineering team has determined that this issue behaves as intended based on the information provided. In your sample code, you’re passing 0 as the options to `enumeratorAtURL:` [fileManager enumeratorAtURL:fwURL includingPropertiesForKeys:@[NSURLIsDirectoryKey] options:0 errorHandler:…] That 0 means “NSDirectoryEnumerationSkipsSubdirectoryDescendants”, and according to the header, “it cause NSDirectoryEnumerator to perform a shallow enumeration and not descend into directories it encounters.”This is clearly not the case: NSDirectoryEnumerationSkipsSubdirectoryDescendants is defined as 1UL << 0.Anyone care to give me a sanity check on this?

I'm having trouble notarizing today. Xcode submits apps OK, but it continues to show `Processing` long after the approval email arrives. if I do the process from the command line (or SD Notary), it uploads fine, notarization-info says it's fine, but stapling fails.The info: RequestUUID: 891514e8-9ffd-... Date: 2019-05-31 01:29:59 +0000 Status: success LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma123/v4/34/06/c7/3406c717-7fe3-f446-a79e-51351df87352/developer_log.json?accessKey=155... Status Code: 0 Status Message: Package ApprovedBut stapling:Downloaded ticket has been stored at file:///var/folders/9d/n7rpchy88xlg3b008k8ydqlh0000gn/T/7ca74636[...].ticket. Could not validate ticket for /Users/shane/Library/Developer/Xcode/DerivedData/...App Name.app The staple and validate action failed! Error 65.Is it safe to distribute such an app without stapling, given the problem looks to be just at that point? Or do I have to wait until the problem is fixed? (I'm seeing others report the same problem.)