Live data from Hacker News

About the security content of Security Update 2017-001

support.apple.com

101–110 of 158 posts

Re: About the security content of Security Update 2017-001

#101
post #26

Earlier quoted context omitted.

That's kind of what it was: https://objective-see.com/blog/blog_0x24.html

It seems to me that the biggest problem highlighted by the link in parent is backwards compatibility of authentication metchanisms. OSX seems to support typical /etc/passwd hashed-user-credential authentication. However, it tries to "upgrade" that authentication mode to "shadowhash or securetoken", which appear to be two new auth schemes integrated with Open Directory. All of those things might be fine, on their own.…

Mac OS X has always used POSIX compliance as a selling point. Would the change you're suggesting break that?

Re: About the security content of Security Update 2017-001

#103
post #90

Earlier quoted context omitted.

Following and furthering your logic, what the hell could they have been doing in the codebase to revert a control mechanism that was effective up to and including 10.12.6, but unsafe as of 10.13.0 onwards???

A graceful upgrade mechanism towards a new password hashing algorithm.

Change is so, so risky.

Re: About the security content of Security Update 2017-001

#104

> it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra So uh... where are all those people who lost their mind about Windows 10 forcing updates? http://i2.kym-cdn.com/photos/images/newsfeed/001/042/619/4ea...

It's only automatic if you have the option enabled which is the default behaviour, it isn't 'forced'. This update doesn't even need a restart.

Re: About the security content of Security Update 2017-001

#106
post #104

> it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra So uh... where are all those people who lost their mind about Windows 10 forcing updates? http://i2.kym-cdn.com/photos/images/newsfeed/001/042/619/4ea...

It's only automatic if you have the option enabled which is the default behaviour, it isn't 'forced'. This update doesn't even need a restart.

That's not what is being reported on daringfireball (emphasis added):

"This morning, as of 8:00 a.m., the update is available for download, and starting later today it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra."

Re: About the security content of Security Update 2017-001

#107

> it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra So uh... where are all those people who lost their mind about Windows 10 forcing updates? http://i2.kym-cdn.com/photos/images/newsfeed/001/042/619/4ea...

People weren't upset about windows installing security updates. If this update adds nagware to OSX or forces people to restart their computer in the middle of whatever they are working on, your comment will be a fair point. Until then, it is an stupid comparison.

People were upset with Windows 10 for it's update policies for a number of different reasons but those very different reasons have all been lumped together into a singular general objection so that addressing one of those reasons will never solve the objection thus making the only possible solution disabling Windows Update. It's silly.

Feature updates and quality updates are handled differently in Windows 10. You can delay feature updates for a year, quality updates (security) can only be delayed for a month.

I'm not sure what specific thing you're referring to when you say "nagware", seem my first paragraph, but there's no persistent nagging in Windows 10.

Re: About the security content of Security Update 2017-001

#108

Earlier quoted context omitted.

They may have even had a test case that entered "root" and no password and hit OK once , but that wouldn't have caught it. What if you'd had to hit "OK" forty-one times to trigger the bug? It's deeply unsatisfying to just say "the problem space is so vast that it's hard to even know what to try beyond the basics that every QA person knows" but I don't personally have a better answer than that. Maybe those that study…

Where are all the unit/integration tests for the APIs that this damned button is calling? Hindsight being 20/20, but I cannot imagine not asserting that a newly created/re-enabled root user has a non-empty password.

The code was not supposed to enable the root user in the first place, so I'd be surprised if someone added an assertion that anything about the root user's account was set. It was only supposed to check the root user's password.

I suppose you could write an assertion that the code didn't enable the root user, but I'm pretty sure that no password-validation routine anywhere in the history of the world has ever had a test case to make sure it didn't modify the account while validating it.

These are unknown unknowns. If you knew enough to write the right test, you wouldn't have written the bug in the first place.

Re: About the security content of Security Update 2017-001

#110
post #104

Earlier quoted context omitted.

It's only automatic if you have the option enabled which is the default behaviour, it isn't 'forced'. This update doesn't even need a restart.

That's not what is being reported on daringfireball (emphasis added): "This morning, as of 8:00 a.m., the update is available for download, and starting later today it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra."

I'm telling you how it is because I just did it myself, in App Store -> Software Update the update was there asking me to install it. There are options in App Store system prefs panel that let you change the default behaviour.

That being said, there's no reason why this shouldn't be applied automatically.

Post reply on HN