28 comments

[ 0.22 ms ] story [ 19.3 ms ] thread
" * We have seen a number of cases where a security bug identified * by AI tools is subsequently independently discovered by a * different researcher. This suggests that adversaries who do not * report bugs to OSS projects are likely to be able to discover * these bugs too. Given this, the OpenSSH team will, for now, be * making more frequent releases to get bugfixes into users' hands * more quickly rather than batching them until the next planned * release."
> sshd(8): On OS X SDK >= 27, sandboxing is no longer supported as the API we depended upon has been removed and no obvious alternative provided.

https://github.com/openssh/openssh-portable/commit/d4b4c304a...

Deprecated since Mountain Lion. https://issuetracker.google.com/40474030

It’s what Apple experimented with before they came up with the current entitlements system.

So Apple had 14 years to work with OpenSSH, and instead chose to break sshd sandboxing?
Entitlements are a great system for user applications, but pretty much unusable for OSS system applications as AIUI they need codesigned binaries
They could have designed a system to put the code signature inside Mach-O but they chose not to.
Code signing and entitlements are integrated into the binary.

(Restricted entitlements require a provisioning profile which requires a bundle, but restricted entitlements are pretty rare)

I wouldn’t really say it compares to entitlements
I look forward to seeing if Apple makes any changes in the fork they ship with the OS: https://github.com/apple-oss-distributions/OpenSSH.

"Updated sandbox for privilege-separated pre-authorization sshd process" is listed as a modification to the open-source project, but I suspect this is out-of-date.

(comment deleted)
I’m confused why they can’t just write a sandbox profile that does the equivalent
Who is "they" ? AFAIK the OpenSSH team focuses on the OpenBSD version and others people/teams use the new releases to create/update a portable version.

So I think it would be up to the team that ports it to Apple, so I think the "Apple Team" is the ones who would worry about sandboxing.

OpenSSH -portable is maintained by the OpenSSH developers, who are also OpenBSD developers.
Mostly correct. The majority of work in both is currently done by Damien and myself, who work on both.

There are a couple of people who have done significant work on OpenBSD's ssh (eg Markus, Theo) and various OpenBSD folks who add a feature or fix a bug and move on.

There is one person who currently works exclusively on -Portable (Tim Rice, who is still around although not very active these days) and at least one other in the past (Andre Lucas, who wrote the multi-platform login recording code). You can see the current set here: https://github.com/openssh/openssh-portable/blob/master/.git...

Are sandbox profiles (or how to use them) officially documented anywhere (as non-deprecated)?

They just got burned by the documented usage of sandbox_init() going away (which didn’t even get a mention in the release notes), I can understand why they’d be unexcited about moving to a different deprecated/undocumented API.

It's an API that a lot of software uses (as opposed to the thing that they were using, which ~nobody used)
I think this is much healthier approach to AI reports than curl has. But I understand both sides.
OpenSSH don't have the same luxury of being able to ignore potential vulnerabilities.
Really glad to see the rate of security fixes speeding up.
They mention a donation link: https://www.openbsd.org/donations.html

I wonder what their funding is like.

I found a small bug in QoS handling in the OpenSSH client under specific conditions. It had a big impact on my workflow but wasn’t a complete showstopper and might not have had an obvious impact on the broader user base. I raised an issue on the tracker and within a day I had a test build, a confirmed fix and a note of which release would carry the fix. It was one of the most positive experiences I’ve had reporting a bug, especially for a non-security issue.

I know this comment doesn’t add much to the conversation about this release, but I’m very grateful to Damien (who handled the issue) and the team for the wonderful job they’re doing on such a core piece of software.

Link or didn't hapen /s

But seriously if feasible, share the issue link. Especially when there's conversation involved, it's different kind of nice (and learning opportunity) reading such thread

Had the same experience with the OpenRewrite lately.
The big ticket thing here seems to be mitigation of "Crossing The Streams", a CRIME-style compression side channel that relies on the fact that different sessions share LZ77 state:

https://arxiv.org/pdf/2609.07709