EagleFiler 1.9.15
EagleFiler 1.9.15 is a maintenance release for my Mac information organizer app. This version greatly improves the quality of imports from X/Twitter and expands the import-tweet-via-hotkey support to more browsers. Preserving the selected text when capturing whole Web pages also works in non-Safari browsers now.
Some interesting bugs were:
macOS Sequoia has changed the way filename extensions are parsed. The documentation still says “The path extension is the portion of the last path component which follows the final period, if there is one.” However, invisible files with no basename (e.g. ..tiff) are now reported as having no path extension (and thus no file type) at all.
Recent versions of Safari include the profile name in the document name (not just in the window title), which seems like a bug to me, but now we work around that. (Safari also sometimes does this when printing a page to PDF.)
For several years, a small yet significant percentage of my customers have been unable to download and install my apps because macOS incorrectly reports them as damaged. The disk image’s checksum, the code signature on the app, and the notarization all check out. It’s not actually damaged. Yet macOS insists, and Gatekeeper can’t be overridden using the contextual menu or System Settings. I had been recommending that such customers redownload the app using Terminal and
curl, as that avoids the file quarantine. However, there’s now an easier solution: a Download Fixer tool that will “fix” an already installed app that’s “damaged” after verifying the code signature.Sandbox testing of Mac App Store receipts seems to be broken again, and the usual cache resetting didn’t work, either. I was able to test it on a fresh macOS installation, though. I’ve seen some reports of Sequoia-specific problems but haven’t seen them myself.
Previously:
- Sequoia Removes Gatekeeper Contextual Menu Override
- EagleFiler 1.9.14
- Code Signing Woes
- Twitter Now Requires Logging In
- Safari 17 Profiles
- Broken Renewal of MAS Receipts
- Distributing Mac Apps Without Notarization
- “Damaged” Apps That Can’t Be Opened
9 Comments RSS · Twitter · Mastodon
Thanks for the .pathExtension note. I wonder if it's related to commit #361efcf in swift-foundation (recent path extension things).
Can the user get the same error trying to launch the Download Fixer tool? I'm ignorant of extended attributes and quarantine flag behaviors, but if the .dmg is "quarantined" are its mounted contents also "quarantined"? Is xattr -rd com.apple.quarantine the fallback?
@Hammer Yes, it certainly seems consistent with the new behavior, though even on Sequoia I don’t think the Objective-C API that my app is using calls into the Swift implementation.
Yes, in theory the Download Fixer could face the same problem itself, but in my experience the damage problem seems to affect apps that had been previously installed. So hopefully the Download Fixer itself would be OK. Yes, everything on the .dmg becomes quarantined when copied off the .dmg. xattr does work to clear the quarantine.
Too bad Download Fixer doesn't work for other apps. I'd pay for an app that just runs in the background and fixes all broken apps in the Applications folder.
Last year I encountered an issue that macOS reporting our app is damaged despite all checks for signature and notarization looks fine, so we have to consult the system log. It was actually caused by upgrading CocoaPods, which adds a rpath pointing outside of the application bundle. https://github.com/CocoaPods/CocoaPods/issues/10954.
The thread would also be helpful when diagnosing such issue: https://forums.developer.apple.com/forums/thread/706414.
@Plume Any idea why you have a lot of broken apps installed? I wonder if this is a different problem if it’s not happening at first install. The Download Fixer approach could work for any app, but my thinking in limiting it to C-Command apps is that I don’t want it to become a vector for helping people distribute malware. So right now it will only process apps that are signed by us.
@Ethan Very interesting, thanks. Were you getting the same error message? On all Macs or only some? I don’t think we have any dangling rpaths. Did spctl --assess say your app was fine?
"Any idea why you have a lot of broken apps installed?"
Some are installed via brew (which has a way to fix the broken apps, I think, but I forget to do it properly every time), but other than that, I don't know. I think I have about a 50% chance of ending up with a broken app, regardless of whether it's a first install or not.
@Plume Ah, I didn’t realize that Brew used the quarantine. But apparently it’s triggering the damaged error for other people, too.
@Michael For that specific issue, it could happen on all Macs as long as the problematic binary is installed. `spctl` command just returns fine, all checks performed by Apparency app (https://mothersruin.com/software/Apparency/) returns OK as well.
I have just checked the receipt validation issue. macOS Sequoia introduced randomized mac address. But it doesn't create problem if one is using apple sample code. The linked github issue uses some other way of obtaining mac address. One can verify using `ioreg -rl -c AppleBCMWLANSkywalkInterface`
