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

91–100 of 157 posts

Re: About the security content of macOS Tahoe 26.6

#91

Post by embedding-shape »

DavideNL wrote: post #85
embedding-shape wrote: post #36

Earlier quoted context omitted.

Same thing happens almost every release. I've stopped updating my Mac machine until I see something in the release notes I literally have to have in order to continue doing macOS/iOS builds, otherwise I'm staying on the version I've validated to work, and I know the existing bugs with.

A better strategy would probably be to stick with the previous *major* release, but, do install its ("minor") security updates...

> do install its ("minor") security updates

Yeah, I thought so too, but surprise surprise; some months ago one of the "minor" updates "broke" ("upgraded") something that made my CI/CD setup stop working, that's when I dropped the idea that Apple even do "minor" updates anymore.

Re: About the security content of macOS Tahoe 26.6

#92

Post by classified »

noname120 wrote: post #88
illithid0 wrote: post #40

Earlier quoted context omitted.

Also a liquid glass hater, but for what it's worth, 27 is supposed to make it a little bit better. I would prefer to go back to what I had before I had to upgrade into this horrible UI, but this is better than nothing. https://www.cultofmac.com/news/liquid-glass-changes-ios-27-m...

macOS 17 is decisively faster on my MacBook Air M1 16 GB than macOS 26/27 is on my MacBook Pro M2 Max 32 GB. And I don’t mean just the animations themselves but lag/sluggishness/responsiveness in general.

There is no macOS 17.

Re: About the security content of macOS Tahoe 26.6

#93

Post by classified »

carra wrote: post #54
tengwar2 wrote: post #33

15.7.8 is out today as well, with these security fixes: https://support.apple.com/en-us/128071 . For context, there have been issues with MacOS 26 which have led many people to defer upgrading until MacOS 27 is available, and MacOS 15 is the previous version.

Are there no versions between MacOS 15 and 26???

No, 26 is the successor of 15. They changed the numbering to year-based.

Re: About the security content of macOS Tahoe 26.6

#94

Post by claiir »

embedding-shape wrote: post #2

Lots of "in collaboration with Claude and Anthropic Research" mentions, no mentions of other labs. I'd assume Apple already had access to whatever the most powerful model is at the various US-based labs, but perhaps not?

also “ Using GLM From Z.AI”

Re: About the security content of macOS Tahoe 26.6

#95

Post by embedding-shape »

lapcat wrote: post #47
embedding-shape wrote: post #2

Lots of "in collaboration with Claude and Anthropic Research" mentions, no mentions of other labs. I'd assume Apple already had access to whatever the most powerful model is at the various US-based labs, but perhaps not?

> Lots of "in collaboration with Claude and Anthropic Research" mentions I wouldn't say 4 is lots. The entire list is massive. I haven't counted myself, but someone claimed that macOS 26.6 has the all-time record with 155 CVEs.

Considering that in Feb 2026 (https://support.apple.com/en-us/126348) Claude wasn't mentioned even once, 4 sure sounds like "lots" compared to nothing :) But you're right, it's subjective ultimately.

Re: About the security content of macOS Tahoe 26.6

#96

Post by pjmlp »

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…

Which is why WG14 and WG21 caring about security would be quite relevant, but alas, priorities.

C could have gotten slices already in the 90's, the concept already existed in other languages, and even Dennis Ritchie made a fat pointer proposal into that sense.

The others, let see if anything related to profiles actually gets into C++29.

Re: About the security content of macOS Tahoe 26.6

#97

Post by pjmlp »

zbentley wrote: post #71
bluecalm wrote: post #21

Earlier quoted context omitted.

>>, 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 are always exposed to the world network. You need also factor development time and ease of finding developers willing to work in a specific language. There are other factors like readability of the code (very verbose languages are likely to be worse) and cos…

> very verbose languages are likely to be worse Citation needed. I don't think there's a correlation there. Over-architected Java spaghetti is verbose and unmaintainable. Under-architected Perl code golf that metastisized is terse and unmaintainable. > languages forcing a lot of abstractions are likely much worse Citation needed. C++ has had some very high-level abstractions on top of a low-level runtime for awhile,…

Even C can be super abstracted, see early 1980-90's business software written in C, with nice stuff like Yourdon Structured Method, leading to over-architected C spaghetti with macros, a decade before Java came to be.

The problem is the lack of interest since Morris worm came to be, to provide better mechanisms in said languages, until governments and key big tech names decided it was time to change existing practices.

Re: About the security content of macOS Tahoe 26.6

#98

Post by catlifeonmars »

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…

How would you enforce a single implementation of path parsing?

Re: About the security content of macOS Tahoe 26.6

#99

Post by pmdr »

jghn wrote: post #37
tengwar2 wrote: post #33

15.7.8 is out today as well, with these security fixes: https://support.apple.com/en-us/128071 . For context, there have been issues with MacOS 26 which have led many people to defer upgrading until MacOS 27 is available, and MacOS 15 is the previous version.

> For context, there have been issues with MacOS 26 which have led many people to defer upgrading For me the issue is liquid glass. Which I doubt is getting fixed any time soon

I bought a MBP mainly for the hardware, otherwise I'd have stuck with Linux. OS-wise, the jump from Monterey (which I'd last used) to Sequoia was smooth and still feels that way. I prefer not to notice the OS at all, something that I feel would be hard to do on Tahoe due to all that liquid glass and dumb transparency and animations.

Seriously, who the heck even asked for those?

Re: About the security content of macOS Tahoe 26.6

#100

Post by acuozzo »

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?

Post reply on HN