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

About the security content of macOS Tahoe 26.6

support.apple.com

Post reply on HN
Print view View original

111–120 of 157 posts

Re: About the security content of macOS Tahoe 26.6

#111

Post by TheJoeMan »

acuozzo wrote: post #100
TheJoeMan wrote: post #86

This may be a naive take, so if anyone has insight please feel free to share, but across Windows, Mac, and Linux OS's I see many cases of path parsing vulnerabilities resulting in sandbox escapes, code execution, or data access issues. When presenting the user with a file picker or command-line input, is it really needed that the software can handle the full POSIX spec? I do not see a "typical" user needing to access…

> I do not see a "typical" user needing to access a path with say... Typical users run software written by atypical users. > some sort of OS-wide single-implementation How do you propose handling migration? What if someone tries to expand an old archive file containing a now-forbidden path?

What I mean is that for “honest” software, built-in to the OS or otherwise, the programmer finds a situation where they take some user-supplied input and concatenate that into a path, and call something like OS.read(). If they want to prevent the user from causing havoc, they now find themselves dealing with path validation in their software instead of calling OS.safeOpen(), which would be a reduced subset of allowed chars?

Re: About the security content of macOS Tahoe 26.6

#112

Post by alwillis »

ajmurmann wrote: post #62
makeitdouble wrote: post #55

Earlier quoted context omitted.

> high ranking Apple employee Jony Ive basically works for Open AI (it's more complicated, but it's a good approximation), and has more or less rebuilt a designing team over there. He's not the central person mentioned in Apple's accusations but that's arguably the central point that's triggering all of this.

Didn't he live Apple a very long time ago?

He left in 2019 and formed his own company, that did design work for Apple until 2022.

He "took" several Apple employees with him when he left and there's been a steady stream of Apple employees going to OpenAI.

Ive isn’t responsible for all of them obviously, but the articles about lawsuits says there are 400 former Apple employees at OpenAI.

Re: About the security content of macOS Tahoe 26.6

#113

Post by alwillis »

MBCook wrote: post #70
mholm wrote: post #66

Earlier quoted context omitted.

I don't believe it's published anywhere, but it's common knowledge to Apple engineers. I can second the poster's assertion that they run Claude internally.

I know they use it, they host it too? That would be a very Apple thing to do.

> That would be a very Apple thing to do.

That's something Steve Jobs would have done.

Re: About the security content of macOS Tahoe 26.6

#114

Post by SoftTalker »

TheJoeMan wrote: post #111
acuozzo wrote: post #100

Earlier quoted context omitted.

> I do not see a "typical" user needing to access a path with say... Typical users run software written by atypical users. > some sort of OS-wide single-implementation How do you propose handling migration? What if someone tries to expand an old archive file containing a now-forbidden path?

What I mean is that for “honest” software, built-in to the OS or otherwise, the programmer finds a situation where they take some user-supplied input and concatenate that into a path, and call something like OS.read(). If they want to prevent the user from causing havoc, they now find themselves dealing with path validation in their software instead of calling OS.safeOpen(), which would be a reduced subset of allowed…

If the OS is working properly, the havoc should just result in "permission denied."

If there's a path on the system that the user should not be able to read, that's the job of the OS to handle, not the individual applications.

Re: About the security content of macOS Tahoe 26.6

#115

Post by pjmlp »

snvzz wrote: post #35
pjmlp wrote: post #18

Map the amount of fixes with "... improved bounds checking..." , "...improved memory handling..." , "...improved memory management..." into the amount of developer, QA and release management teams salaries per hour, versus other stuff they could be working on, and that gives an approximate value of how using specific languages maps into monetary loss, and why companies are starting to care nowadays, given computers a…

If anything, there's a strong argument to switch to seL4.

Indeed, however without some regulatory help it Will take its time for such kind of improvements across the industry.

Re: About the security content of macOS Tahoe 26.6

#116

Post by SoftTalker »

alwillis wrote: post #112
ajmurmann wrote: post #62

Earlier quoted context omitted.

Didn't he live Apple a very long time ago?

He left in 2019 and formed his own company, that did design work for Apple until 2022. He "took" several Apple employees with him when he left and there's been a steady stream of Apple employees going to OpenAI. Ive isn’t responsible for all of them obviously, but the articles about lawsuits says there are 400 former Apple employees at OpenAI.

Sounds like Apple needs to do a better job at being a place where employees want to stay.

Re: About the security content of macOS Tahoe 26.6

#118

Post by yjftsjthsd-h »

snvzz wrote: post #35
pjmlp wrote: post #18

Map the amount of fixes with "... improved bounds checking..." , "...improved memory handling..." , "...improved memory management..." into the amount of developer, QA and release management teams salaries per hour, versus other stuff they could be working on, and that gives an approximate value of how using specific languages maps into monetary loss, and why companies are starting to care nowadays, given computers a…

If anything, there's a strong argument to switch to seL4.

It was my vague understanding that by the time you implemented all the apis needed to run normal software on top of that, you either have enough apis that different tasks can still compromise each other, or you have shoved everything into a single task with very little isolation between normal user processes. In either case, it doesn't seem like you actually gained so much. What am I missing?

Re: About the security content of macOS Tahoe 26.6

#119

Post by drnick1 »

reddalo wrote: post #81
frizlab wrote: post #61

Earlier quoted context omitted.

macOS 27 does polish Liquid Glass and makes it look passable on macOS IMHO. It was very bad on 26. Comically bad.

That's the sad thing: Apple decided to leave all Intel macs on broken macOS 26. Very bad on Apple's part.

Fortunately, those can run Linux. I recently installed Arch on an Intel T2. The only issue is that it does not have a TPM module, so the LUKS password needs to be manually entered at boot.

Re: About the security content of macOS Tahoe 26.6

#120

Post by acdha »

zbentley wrote: post #68
acdha wrote: post #44

Earlier quoted context omitted.

> You need also factor development time and ease of finding developers willing to work in a specific language This even more strongly favors Rust or Swift. Nobody is writing C or even Objective-C in 2026 as a growth language.

If you just meant apple-targeting developers, then yeah; you're right that those languages are in decline. But if you meant developers in general, I think you'd be surprised how many growth sectors are hiring C programmers. They're often not SaaS tech companies, but they are massive and many are growing. Hardware, industrial control systems, defense/aerospace ... there's a ton there, the spaces in which they hire jus…

[dead]
Post reply on HN