←back to thread

MacOS Catalina: Slow by Design?

(sigpipe.macromates.com)
2031 points jrk | 1 comments | | HN request time: 0s | source
Show context
davidvartan ◴[] No.23273396[source]
> a degraded user experience, as the first time a user runs a new executable, Apple delays execution while waiting for a reply from their server.

The way to avoid this behavior is to staple the notarization ticket to your bundle (or dmg/pkg), i.e. "/usr/bin/stapler staple <path>." Otherwise, Gatekeeper will fetch the ticket and staple it for the user on the first run.

(I'm the author of xcnotary [1], a tool to make notarization way less painful, including uploading to Apple/polling for completion/stapling/troubleshooting various code signing issues.)

[1] https://github.com/akeru-inc/xcnotary

replies(5): >>23273530 #>>23273867 #>>23273940 #>>23275792 #>>23279360 #
scottlamb ◴[] No.23273940[source]
> The way to avoid this behavior is to staple the notarization ticket to your bundle (or dmg/pkg)

Maybe in some cases, but the article says "even if you write a one line shell script and run it in a terminal, you will get a delay!"

Shell scripts don't come in bundles. I don't think this kind of stapling is possible for them? I don't think it'd be reasonable to expect users to do this anyway.

replies(1): >>23274045 #
davidvartan ◴[] No.23274045[source]
The Gatekeeper behavior is specific to running things from Finder (not Terminal), and only if you downloaded it via a browser that sets the com.apple.quarantine xattr.

Two posts from Apple dev support (Cmd+F "eskimo") describe this in more detail.

https://forums.developer.apple.com/thread/127709

https://forums.developer.apple.com/thread/127694

replies(4): >>23274142 #>>23274402 #>>23275448 #>>23278587 #
nemosaltat ◴[] No.23274142[source]
I recently learned that `xattr -cr path/to/my.app` solves the “this App is damaged would you like to move it to the trash” you get when you copy an app from one Mac to another.
replies(1): >>23274362 #
rhizome ◴[] No.23274362[source]
That might be the Windows-iest feature of OSX I've ever heard of.
replies(2): >>23274887 #>>23275013 #
cosmojg ◴[] No.23274887[source]
It seems macOS is going downhill fast these days.
replies(1): >>23275418 #
withinboredom ◴[] No.23275418[source]
No, it’s just that they’re becoming more popular. When you become a popular desktop OS, governments and militaries want to start using it which comes with some strange requirements. It also means that you can’t rely on “obscurity” to provide any sort of security, where before you could overlook some things.
replies(1): >>23275723 #
catalogia ◴[] No.23275723[source]
Can you cite any sources for your claim that these things are being implemented to satisfy government/military requirements?
replies(1): >>23276209 #
o-__-o ◴[] No.23276209[source]
DISA?

I don’t know why grand op is downvoted. DoD requirements literally require a timeout setting for screensavers to begin locking. This has caught systems which have a race condition where you can move your mouse quickly and gain desktop access before it locks.

The long term effects come from the required changes to the development security model to remain productive and profitable (took MSFT a few OOB hotfixes and service packs to fix that example above, look when gnome kde xscreensaver etc introduced that feature etc)

replies(1): >>23278090 #
saagarjha ◴[] No.23278090[source]
> This has caught systems which have a race condition where you can move your mouse quickly and gain desktop access before it locks.

I fail to see how this is a race condition rather than how a screensaver is supposed to work?

replies(1): >>23278603 #
1. o-__-o ◴[] No.23278603[source]
Because it’s not, that’s why I pointed to xscreensaver feature implementation. Lock time is separate from screensaver activation time which is separate from energy saving activation time.

What defines when a locking screen saver is “locked”? 10m? Or 10m1s? You are making assumptions and that is what DISA spells out. Which forces the OS design to change in subtle ways. Like xattrs on files as great grand op was alluding to.

Does that provide clarity into how development security models evolve over the lifetime of an application?