Right, you get it in toto IMHO: this is the least worst thing they can say, and also the best thing they can say.
If they don't apologize, that'd be worse.
If they don't indicate they'll take steps to prevent this from happening in the future, that'd be worse.
If they had all the steps ready right now, I'd be confused because they should have A) fixed the bug B) deployed the fix C) communicated the bug exists and a fix was deployed. Blending that with D) postmortem would show an undisciplined approach.
If they claimed the ability to prevent all bugs ever, or at least, all unintentional file writes, I'd be confused because it's impossible to prove it never writes to a file.
A good start is to do what he did (delete the ssh logging altogether), and start investigating automated ways to validate if/when files are accessed. The cool thing about macOS dev is there's a ton of tooling that leaps and bounds beyond cross-ecosystem tooling. I wouldn't be very surprised if someone linked an obscure mid-1990s technical note that lets you set an NSArray of paths that are allowed access, or if Instruments had some built-in dtrace integration that could pull this off. Couple running that in CI, make sure you got test coverage, and you've done the best you can.
(n.b. a lot of it seems to hinge on "I deeply regret this mistake and will take steps to ensure it never happens again." being read as "I deeply regret this mistake. I will do things until I can, absolutely, 100%, foreever, guarantee it'll never ever happen again." For the young and impressionable: the blog post is great, there's ~0 you could do better here)
Better would say "After the immediate problem is patched, I will post more details about future plans for security, probably within X days. I welcome suggestions on the feature tracker."
Empty vague promises aren't really better than being quiet. They rely entirely on the reader's good faith, but if that good faith exists (which it likely does for this excellent product and excellent developer), then the promise adds no information.
If they don't apologize, that'd be worse.
If they don't indicate they'll take steps to prevent this from happening in the future, that'd be worse.
If they had all the steps ready right now, I'd be confused because they should have A) fixed the bug B) deployed the fix C) communicated the bug exists and a fix was deployed. Blending that with D) postmortem would show an undisciplined approach.
If they claimed the ability to prevent all bugs ever, or at least, all unintentional file writes, I'd be confused because it's impossible to prove it never writes to a file.
A good start is to do what he did (delete the ssh logging altogether), and start investigating automated ways to validate if/when files are accessed. The cool thing about macOS dev is there's a ton of tooling that leaps and bounds beyond cross-ecosystem tooling. I wouldn't be very surprised if someone linked an obscure mid-1990s technical note that lets you set an NSArray of paths that are allowed access, or if Instruments had some built-in dtrace integration that could pull this off. Couple running that in CI, make sure you got test coverage, and you've done the best you can.
(n.b. a lot of it seems to hinge on "I deeply regret this mistake and will take steps to ensure it never happens again." being read as "I deeply regret this mistake. I will do things until I can, absolutely, 100%, foreever, guarantee it'll never ever happen again." For the young and impressionable: the blog post is great, there's ~0 you could do better here)