undefined | Better HN

0 pointseridius8y ago0 comments

> Safari couldn't even render apples website correctly. Nor could Safari connect to any site with HTTPS.

Sounds like something's wrong with your friend's computer, because neither of those issues are reasonable to expect no matter what your opinion of Apple's software is.

> But the submit button on their developer site is broken

Given the number of people who've successfully gone through that form, I'm willing to bet it's a content blocker extension that's blocking some dependency the form needs.

> And now shipping an operating system with a root account with no password by default.

The OS actually ships with root disabled. The bug isn't that there's no password (after all, a factory-set password isn't any more secure), the bug is that the login form is somehow re-enabling the root user when it's not supposed to be able to do so.

0 comments

2trill2spill8y ago

> Sounds like something's wrong with your friend's computer, because neither of those issues are reasonable to expect no matter what your opinion of Apple's software is.

Doubtful Firefox and Chrome work just fine.

> Given the number of people who've successfully gone through that form, I'm willing to bet it's a content blocker extension that's blocking some dependency the form needs.

Brand new install of Mac OS on a new SSD. So Safari was clean no extensions, no custom configuration.

> The OS actually ships with root disabled. The bug isn't that there's no password (after all, a factory-set password isn't any more secure), the bug is that the login form is somehow re-enabling the root user when it's not supposed to be able to do so.

Mere semantics, It doesn't matter if root is being "reenabled" or not. From an attackers point of view High Sierra effectively ships with root with no password.

eridiusOP8y ago

> Doubtful Firefox and Chrome work just fine.

That doesn't mean anything. It just means that whatever is messed up affects Safari. It's not like the computer recognizes "oh those 3 apps are all web browsers, therefore if I'm going to screw one of them up, I have to screw them all up". Your claim would carry more weight if you were listing multiple browsers that all use the same system-provided WebKit.framework, but Firefox and Chrome are completely separate browsing engines.

Regarding the HTTPS issue, I believe Firefox and Chrome maintain their own list of root certs, so one possible way the computer could be screwed up is having the system-managed root cert list be damaged (you didn't specify what actually happens when trying to connect to HTTPS sites so I don't know if this is actually a plausible cause in this particular case).

> Brand new install of Mac OS on a new SSD. So Safari was clean no extensions, no custom configuration.

Well I don't know what to tell you, except to point out that there's, what, hundreds of thousands of registered Apple developers now? who've all had to go through that form, and there's only a handful of people on that thread, so it's far more likely to be a local issue.

2trill2spill8y ago

> That doesn't mean anything. It just means that whatever is messed up affects Safari. It's not like the computer recognizes "oh those 3 apps are all web browsers, therefore if I'm going to screw one of them up, I have to screw them all up". Your claim would carry more weight if you were listing multiple browsers that all use the same system-provided WebKit.framework, but Firefox and Chrome are completely separate browsing engines.

That fact that everything besides Safari works certainly means something and the fact that they have different rendering engines is irrelevant. What is relevant is whether a site renders in a browser or not.

> Well I don't know what to tell you, except to point out that there's, what, hundreds of thousands of registered Apple developers now? who've all had to go through that form, and there's only a handful of people on that thread, so it's far more likely to be a local issue.

Well that's just one example of dozens of people having that problem. Also I have successfully filled out that form my self in the past, as I am a registered apple developer. But just because large amounts of people can use the form successfully does not mean that there isn't a bug affecting other user's like my friend.

mostlyskeptical8y ago

>neither of those issues are reasonable to expect no matter what your opinion of Apple's software is.

Neither is your password showing up in a password hint field (or anywhere for that matter... why is it even stored unhashed?).

Neither is logging in with a blank password enabling a disabled root user.

eridiusOP8y ago

> Neither is your password showing up in a password hint field (or anywhere for that matter... why is it even stored unhashed?).

It's not stored unhashed. And the password hint field never showed the password, it always showed the password hint.

The bug was Disk Utility's UI was accidentally using the password field instead of the password hint field when passing the data to the underlying API.

> Neither is logging in with a blank password enabling a disabled root user.

Stupid and awful bug, sure, but I actually can understand it. Something that's worked fine for years breaks because of some change to some underlying system, and there weren't any existing tests to see what happens if you try and log in as root (root has been disabled by default for something like 15 years, so it doesn't surprise me that people don't test trying to log in with it).

But apple.com not rendering right in Safari? That doesn't make sense, you know damn well apple.com is basically designed to be viewed in Safari and everybody that works on it is going to be using Safari with it.

And Safari not being able to load HTTPS sites makes even less sense. That literally breaks most of the web. This has to be an issue with the local computer.

j / k navigate · click thread line to collapse

0 comments

2trill2spill8y ago

> Sounds like something's wrong with your friend's computer, because neither of those issues are reasonable to expect no matter what your opinion of Apple's software is.

Doubtful Firefox and Chrome work just fine.

> Given the number of people who've successfully gone through that form, I'm willing to bet it's a content blocker extension that's blocking some dependency the form needs.

Brand new install of Mac OS on a new SSD. So Safari was clean no extensions, no custom configuration.

Mere semantics, It doesn't matter if root is being "reenabled" or not. From an attackers point of view High Sierra effectively ships with root with no password.

eridiusOP8y ago

> Doubtful Firefox and Chrome work just fine.

> Brand new install of Mac OS on a new SSD. So Safari was clean no extensions, no custom configuration.

2trill2spill8y ago

mostlyskeptical8y ago

>neither of those issues are reasonable to expect no matter what your opinion of Apple's software is.

Neither is your password showing up in a password hint field (or anywhere for that matter... why is it even stored unhashed?).

Neither is logging in with a blank password enabling a disabled root user.

eridiusOP8y ago

> Neither is your password showing up in a password hint field (or anywhere for that matter... why is it even stored unhashed?).

It's not stored unhashed. And the password hint field never showed the password, it always showed the password hint.

The bug was Disk Utility's UI was accidentally using the password field instead of the password hint field when passing the data to the underlying API.

> Neither is logging in with a blank password enabling a disabled root user.

And Safari not being able to load HTTPS sites makes even less sense. That literally breaks most of the web. This has to be an issue with the local computer.

j / k navigate · click thread line to collapse