Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I thought I was going crazy! It works fine back to a machine running 10.12.6.

MacPro6,1 10.13.1 with update to MacBookPro14,3 10.13.1 with update is failing without cause. I've tried as Guest, Registered User, and with Apple ID.

Seriously Apple!


I've tried all troubleshooting steps I know of and there's nothing we can do for now. The target system rejects the credentials used to connect only on File Sharing. Surely there will be a further update to correct this issue. In the meantime, if something comes up I'll let you know.
 
Please don't be silly , seriously, there is no such thing as 100% bug-free software..... that is why we have priorities / serverity, lowest level bugs are just not with the effort or business value to resolve ....

What you are dealing with here is highest priority critical bug....

Do you understand how bad this is ? Macs with guest accounts .... and there are so many instances where these are used on companies , schools, institutions etc.... can gain root access ? You understood the severity right ?

Sorry , anyone playing this down, or viewing this as an acceptable "bug" does not understand that the issue here is.

While so many of the apologists are too busy Missing the point, thankfully Apple is not and has issues the patch....

You also ignored my question in relation to software development. I assume you were not a software engineer ? If you were please answer my question , otherwise please don't speak for us and the silly notion of 100% bug free software development ...

Of course I understand how bad that is. Who is saying it's an acceptable bug? No one here - that's a straw-man you're creating simply to create drama where none is necessary. Most everyone here gets it without need for your assistance. There is no perfection and stuff happens, no matter how robust you believe your test plan is.

And, I'm not minimising the bug at all. What I'm saying is it's virtually impossible to test all corners of a piece of complex software such as an OS. Some bugs that creep in will be innocuous. Some will be incredibly important. You don't get to choose what kind and where they'll show up, no matter how comprehensive and robust you believe your test plan is.

The important thing is Apple jumped on it immediately the first day it was revealed, with a temporary user-fix. And then, in less than a day's time, had a solution that solved the problem. That's what counts.

" You also ignored my question in relation to software development. I assume you were not a software engineer ?"

Well, you've assumed wrong - which is not surprising based on your earlier characterizations - the latest suggesting I speak for "us," meaning all software engineers. As I mentioned in the past, I'm a hardware and systems engineer, mostly architecting and setting requirements for hardware-based high-speed signal processing systems that include software, but from time to time in the past have written my share of software supporting various projects and teams to help out as a software engineer, using various languages, at both the hardware and operator interface level. As I do with hardware design as well. I have also written specs and proposals for projects where software was a major part of the project. And have also managed software engineers as a program manager for deliverable projects. And I even write manuals, when necessary.

But that's neither here nor there.
 
  • Like
Reactions: unsharptooth
I find this issue so bizarre and hard to understand how it got into the os release in the first place. Glad it's fixed but it does sow doubt in an otherwise secure bit of kit.
 
The problem is not being bug-free or not bug-free. The problem is that its an extremely glaring and obvious hole that should have been caught by automatic tests! Checks whether the root user is automatically enabled are the most obvious thing to test for. What this situation shows is that software development policies at Apple are completely and utterly mismanaged. It would be a different thing if we'd have a more obscure bug that occurs on an intersection of several non-trivial features, but its permission for the root user of all things!

Not to mention that its most likely not a bug in the first place. Probably some dev at Apple whitelisting root access for testing purposes and forgetting to reset it after they were done...

Are automatic tests always 100% reliable, checking all corners of all possibilities for all potential disaster situations; ie not this particular situation? For all other companies maybe, and not Apple?
 
Yep. File sharing is failing. After several troubleshooting steps it's now clear that File Sharing is not accepting any credentials to connect to network machine (both running 10.13.1 after Security Update 001). Screen Sharing, on the other hand, works flawlessly!
Yes, filesharing stopped working!
 
  • Like
Reactions: heffsf
Apple should re-examine its insistence on annual iOS and macOS releases if they’re not able to properly test and polish them, or possibly even finish them! iOS 11 in particular took major backward steps this year and is only now approaching the standard we had with iOS 10 three months later.

In my experience, pushing staff to meet unreasonable arbitrary deadlines inevitably has consequences. Yet most managers see it as their role to do so and prefer to overlook the lower quality of work as it suits their financial reporting.
 
It is good the patch was supplied.

Now, let's see some accountability for the folks responsible. Craig Federighi should be sacked immediately as he is ultimately responsible. The chain of responsibility should be traced right down to the cubicle level and those folks should join Craig on the pink slip scaffold.

QC - next in line.

Accountability is a good thing. If you don't enforce it you don't have it. These incompetents did not meet the minimum standards of due diligence.
 
Now, let's see some accountability for the folks responsible. Craig Federighi should be sacked immediately as he is ultimately responsible. The chain of responsibility should be traced right down to the cubicle level and those folks should join Craig on the pink slip scaffold.

They'd have had to have sacked Bertrand Serlet and Scott Forstall (for reasons other than Maps) if that was the policy. There have been root exploits in every version of OS X.

10.3 and 10.4 could be rooted with bluetooth
http://tidbits.com/article/8729

10.5 and 10.6 had some nice rootkits
https://www.macrumors.com/2017/07/27/vault-7-wikileaks-older-macs/

10.7 through 10.10 were vulnerable to root pipe
https://www.exploit-db.com/exploits/36692/

10.11 had a SIP flaw
https://thehackernews.com/2016/03/system-integrity-protection.html

Every jailbreak that ever existed for iOS was a root exploit too. Scott would have been fired a lot of times.
 
  • Like
Reactions: stanwalters
They'd have had to have sacked Bertrand Serlet and Scott Forstall (for reasons other than Maps) if that was the policy. There have been root exploits in every version of OS X.


Exactly my point, no accountability, and we have repeated root exploits. This is unacceptable and will continue as long as it is tolerated. "Well, we've screwed up every time," is hardly an excuse.

How long would YOU tolerate this in an employee?
 
could someone contact apple to tell them that the Build Number does not appear on About Mac - Overview?

The only way to see the build number is by the terminal command
Code:
 system_profiler SPSoftwareDataType

I would do it but I don't know how. please PM me if you do it thanks
 
Exactly my point, no accountability, and we have repeated root exploits. This is unacceptable and will continue as long as it is tolerated. "Well, we've screwed up every time," is hardly an excuse.

How long would YOU tolerate this in an employee?

What you're saying is simply unrealistic. You will not find every exploit in a complex operating system. They exist in IOS, they exist in macOS, they exist in Windows, they exist in Android, they exist in Linux. Firing everyone involved will simply result in less qualified people being in charge.
 
  • Like
Reactions: PickUrPoison
Firing good people for bad mistakes they've since learned from is just not smart, even if you discover multiple past mistakes. . . . .

This is both true and false. Rarely does the real person responsible get disciplined. Usually there is a management person that did not provide enough time, overrode an engineer, made decisions they were not qualified to make, made decisions based on personal or political causes, etc. For example, read about the space shuttle. When the stuff hits the fan in the cases described here the person who was overridden is disciplined, not management or the persons responsible. Why? Because they have the power to direct the angst. This says your right.

But anyone that believes that making this kind of mistake if it really was the responsibility of a software engineer should not be fired is just not accustomed to any type of high performance job requirements. This says your wrong.

And if Apple has a low skill requirement engineer, like a UI engineer, or a QA engineer, working on security, then again that is a management fault. But there is no excuse for this type of error and someone definitely should be fired, but if and only if the real cause and person is known.

Sadly, in a company like Apple it is generally impossible to find the truth amid all of the politics. And the result is that likely, as you have stated, a good engineer will probably get fired to take the heat off of some manager.
 
Did you read about the bug? Its not some kind of easy thing to discover and would easily be passed over by pretty much all testing attempts.

This is why not only did it take until now to discover, but also why companies pay bounties for hackers to find these kinds of things.
Lol are you kidding? Root having no password is something extremely easy to discover. You're clearly trying to talk about something you don't understand.
 
What you're saying is simply unrealistic. You will not find every exploit in a complex operating system. They exist in IOS, they exist in macOS, they exist in Windows, they exist in Android, they exist in Linux. Firing everyone involved will simply result in less qualified people being in charge.




I completely understand that it is an impossibility to produce completely bug free software once you reach a certain level of complexity. Absolutely true.

However, there are bugs and then there are BUGS.

You have to have a certain level of due diligence. I could care less if my emoji "malfunctions" but screwing up root is ignoring securing the most fundamental family jewels. We're not talking about some minor error.

I agree that some engineer should not take the hit alone. Start at the top.
 
  • Like
Reactions: 0837990
My sleeping MacBook just chimed twice, spontaneously. Would that be caused by the new security patch being auto-installed?
 
I completely understand that it is an impossibility to produce completely bug free software once you reach a certain level of complexity. Absolutely true.

However, there are bugs and then there are BUGS.

You have to have a certain level of due diligence. I could care less if my emoji "malfunctions" but screwing up root is ignoring securing the most fundamental family jewels. We're not talking about some minor error.

I agree that some engineer should not take the hit alone. Start at the top.

I think we will have to agree to disagree.

There absolutely should be an inquest, the developer who made the submit should be "talked to" and the development practices should be examined for ways to improve and help prevent a similar issue in future. There's little point looking for blood every time a mistake, even a serious mistake, happens unless the same person shows a pattern of it. They're always going to happen and all you can do is learn a lesson and improve.
 
Anyone having issues with File Sharing after the update?
Rush. Panic. Throw out a patch to fill the immediate glaring issue and worry about the fallout afterwards.

Apple Engineering, who actively read this blog, please get your C-levels to hire back the QA team. QA teams are the heroes who find your bugs. We the developers doing beta installs shouldn't be the QA team.
 
  • Like
Reactions: heffsf
Anyone downplaying this are the ones apple can do no wrong to them. They were the ones "holding it wrong" and said......"you're right"
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.