Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MacOS Catalina: Slow by Design?

sigpipe.macromates.com

Post reply on HN
Print view View original

631–640 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#631

Post by wila »

xenadu02 wrote: post #103
davidvartan wrote: post #5

> 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 ." 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 notariz…

Xcode (the UI) is able to bypass GateKeeper checks for things it builds. The "Developer Tool" pane in System Prefs, Security, Privacy is the same power. Drag anything into that list you'd like to grant the same privilege (such as xcodebuild). This is inherited by child processes as well. The point of this is to avoid malware packing bits of Xcode with itself and silently compiling itself on the target machine, thus b…

GateKeeper only triggers the check for things downloaded from the internet. IOW, it checks if your binary has a quarantine flag attached via an extended attribute.

Re: MacOS Catalina: Slow by Design?

#632

Post by saagarjha »

Someone wrote: post #505
reuben_scratton wrote: post #410

Earlier quoted context omitted.

Quinn The Eskimo at Apple's forums is a 10x support engineer, his posts have helped me fix dozens of problems.

Unless somebody took over his name he’s been at Apple for almost 25 years, and was already being interviewed as such 20 years ago ( http://preserve.mactech.com/articles/mactech/Vol.16/16.06/Ju... ) His site ( http://www.quinn.echidna.id.au/Quinn/WWW/ ) supports its claim “I'm not a great believer in web” :-)

It's interesting to see a time when Apple seemed to allow employees to have side projects…

Re: MacOS Catalina: Slow by Design?

#633

Post by saagarjha »

ihiulll wrote: post #462
davidvartan wrote: post #5

> 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 ." 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 notariz…

I'm confused. does macbook send executable to apple servers or just the hash?

Just the hash.

Re: MacOS Catalina: Slow by Design?

#635

Post by saagarjha »

lioeters wrote: post #606
saagarjha wrote: post #447

Earlier quoted context omitted.

> Lisp interpreter (or maybe compiler? not sure) I believe it is actually a Scheme dialect, and I would be very surprised if it is not compiled to some internal representation upon load. > This capabilities-ruleset interpreter is what Apple uses the term "Gatekeeper" to refer to, mostly. I am fairly sure Gatekeeper is mostly just Quarantine and other bits that prevent the execution of random things you download from…

In the Apple Sandbox Guide v1.0 [1], it mentions Dionysus Blazakis' paper [2] presented at Blackhat DC 2011. In the latter, Apple's sandbox rule set (custom profiles) is called SBPL - Sandbox Profile Language - and is described as a "Scheme embedded domain specific language". It's evaluated by libSandbox, which contains TinyScheme! [3] From what I could understand, the Scheme interpreter generates a blob suitable for…

That sounds about right. I was doing some work in this area very recently, which found a couple of methods to bypass sandboxing entirely, but somewhat humorously the issues did not require me to have any understanding of how the lower levels of this worked ;)

Re: MacOS Catalina: Slow by Design?

#636

Post by bscphil »

andai wrote: post #99
tragomaskhalos wrote: post #60

Earlier quoted context omitted.

That computers are just slower to interact with now is such a truism that we hardly remark upon it any more. It seems utterly insane that in the early 90's I could just run Windows 3.1 on a bit of kit that in all likelihood wouldn't even power a toaster today, and the experience was, well, frictionless. I don't recall ever thinking "wtf is this thing doing ?", whereas today, by contrast, if I have the audacity to be…

Are you on a hard disk drive? I have bestowed upon myself the unique misfortune of running Windows 10 on a spinny disk.

This has quietly become a pretty serious issue. Most software developers have simply stopped caring about systems with traditional HDDs. This is even true on Linux - I found out a while back that all the KDE developers are using SSDs, which is why they weren't fixing issues where startup time is affected by disk latency. I eventually gave in and bought a 250 GB SSD for my old laptop, there was simply no other option.

Re: MacOS Catalina: Slow by Design?

#637

Post by saagarjha »

fxtentacle wrote: post #549
robenkleene wrote: post #172

Earlier quoted context omitted.

Except all of Apple's other devices are built on macOS. Apple's clear de-prioritization of macOS based on revenue numbers is so insane I can barely believe it's happening. If developers, who use Macs in large numbers today, go to another platform, there's very real risk that their entire empire starts to come apart at the seams. And, this may just be me being naive, but it doesn't seem like that much work to keep mac…

Agree. That's probably also one reason why more and more people want to use cross-platform app frameworks instead of developing for iOS natively. That way, you can do most of the dev work on Windows and Android, and you'll only need to use Mac & XCode for compiling the iOS binary. And I'd wager that some iOS games are released without the developer ever touching XCode: https://docs.unity3d.com/Manual/UnityCloudBuildi…

Signing and submitting apps to Apple is fairly annoying to do without Xcode.

Re: MacOS Catalina: Slow by Design?

#638

Post by monadic2 »

cliffsteele wrote: post #615
monadic2 wrote: post #580

Earlier quoted context omitted.

Honestly I'm trying to think of a reason you would WANT to disable OCSP, I'm having enough problems thinking of more than 2 developers I know who can actually articulate how it works enough to evaluate this. Not that it's complicated—it's just mostly invisible. Even when OCSP is a problem, generally you're more worried about issuing a new certificate than an immediate workaround. What are you going to do, ask all you…

Well, security starts from the user. If you're not mindful of what websites you visit, or what files/apps you download and run, there's no OCSP or anything else there to save you. OCSP enabled or not, you're still one website click away from being pwned to oblivion, giving full control to the hacker – which, of course, is inevitable to an extent, since bugs always find their way into software. So why not make it easy…

Well, are you going to manually look up certificate revocations yourself? This necessarily requires a network lookup—you can't just glance at the certificate. What's the benefit of disabling this functionality that actively alerts you to revocations?

> Well, security starts from the user. If you're not mindful of what websites you visit, or what files/apps you download and run, there's no OCSP or anything else there to save you.

Sure, but we're discussing good-faith security here. Presumably if people complain about a missing feature they can envision using it. The scenario here is not visiting a shady website and doing something stupid, the scenario here is something like a man-in-the middle attack using a revoked certificate, which would by definition by difficult for the end-user to detect.

> So why not make it easy to disable?

Because then people would disable it for no discernable good effect.

I mean let me be clear, if you're a security researcher you can just modify your own HTTP stack, run a VM, control the hardware, whatever. This isn't a blocker to investigating HTTPS reactions sans OCSP—this is about denying secure connections when they've publicly revoked the cert used to sign the connection. The only reason this is even considered a discrete feature is that most people have never written an OCSP request in order to then trust an HTTPS server—you're just opening yourself up to be misled without even realizing this (and this goes for most of my very network-stack-aware coworkers).

If you're in a browser, you want the browser to be using best practice security, which necessarily includes OCSP. If you know what you're doing this is trivial to bypass.

Re: MacOS Catalina: Slow by Design?

#639

Post by colejohnson66 »

cliffsteele wrote: post #610
Retric wrote: post #601

Earlier quoted context omitted.

Apple’s rejected a huge number of App updates for security reasons. It’s not a huge benefit, but it does exist.

And also allowed a jailbreak app in the iOS App Store. Yes, it only happened once (that I know of), but it still shows you can't really be oblivious to their practices.

So out of the millions of apps on the App Store, they slipped up once? Sounds like a really good success rate.

Re: MacOS Catalina: Slow by Design?

#640

Post by bgorman »

the_af wrote: post #594
hrktb wrote: post #444

Earlier quoted context omitted.

I only tried Ubuntu, a few month ago. For the day or two spent with it: - multi-language support requires a lot of work to get to the same point as macos. In particular I use third party shortcut mappers to get language switching on left and right command keys (mimicking the JIS keyboards, but with an english international layout). That looks like something I’d have to give up on code myself. - printer support is not…

Fair enough. I'm not a Mac OS X user so I don't know how it would compare. I can only compare it with my past experience with Windows, and I think it's superior (for me) to Windows circa 7 -- I stopped using Windows entirely at that point, so I wouldn't know how later versions of Windows fare. Portability is also a fair issue to raise, but it's simply not a problem for me. When I say Linux "on the desktop", I literal…

Without HiDPI support lots of applications become useless when you use a HiDPI display. Even Steam does not respect HiDPI settings in Gnome 3 even when setting custom environment variables.
Post reply on HN