Reverse Engineering MacOS High Sierra Supplemental Update • Hacker News Board

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#71

Post by veidr » Mon, Oct 09, 2017, 12:05 PM UTC

danra wrote: post #16

It's pretty insane this sort of bug either passed or didn't even go through code review and testing at Apple, a company which has approximately infinite resources and whose marketing pitch is making high-quality products. I loved Apple products and still do, but as both a user of and a developer for their systems, I feel the quality has been steadily going downhill the last few years.

I think you might be looking at the past through rose-colored glasses. Apple's always had horrible show-stopping bugs, in every single OS X / macOS release[1], from when simple operations like updating iTunes or enabling the OS's Guest Mode might delete your home directories, to this latest failure.

I suspect one reason is that they like one-person teams so much. I like one-person projects too! But there is always pain when you have to hand such a project to a new person, because the old one quit, or died, or whatever.

Overzealous secrecy even when not warranted for any actual business-relevant reason also probably inhibits software quality. As does change for change's sake.

[1] EDIT: except maybe Mac OS X 10.6? Does anybody remember any critical bugs in that one? I think that might be the unicorn.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#72

Post by skgoa » Mon, Oct 09, 2017, 12:23 PM UTC

rjzzleep wrote: post #26

tempodox wrote: post #20

Installing a new Mac OS on a machine you care for has become an absolute no-go area. I wait for at least half a year and then only install in a place that I can trash in case I still see problems.

I'm not sure why you say "has become". In the circles I've been it has been common practice to wait for the .2(but minimum .1) release before it goes onto real work machines. The early Mac OS X releases were even worse. Even if for some reason the OS itself was fine by itself, they almost always broke compat with a bunch of 3rd party applications. EDIT: typo

That's the standard MO with pretty much any big piece of software. Other than security updates, you really don't want to take the risk of becoming the one who finds the inevitable bugs.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#73

Post by abalone » Mon, Oct 09, 2017, 12:23 PM UTC

nicolasd wrote: post #17

bsaul wrote: post #13

Seems like Unit testing really is NOT popular at all at Apple. I mean, they release a framework for storage, and they don’t even unit test security related functions ? Tdd introduced the wrong idea that unit tests should be all or nothing. I think it’s not. I unit test only the most critical parts of my programs (and only if there are), and i see value in it.

Serious question: How would you suggest to write a test that prevents this? You wouldn't make an assertion on clearTextPassword !== passwordHint. While developing I would think "Who will ever do that? That would be insane". But yes, even if there is no test, this should have been caught in code review or latest when testing the OS.

You wouldn’t need to test it like that. What’s missing here is simply a test of that StorageKit API that the GUI uses. The test would be straightforward: set all the options and see if the resulting volume is created correctly. So for the hint your test would generate a value — a good test will exercise a range of values over multiple iterations — and verify the hint on the created volume.

No doubt this basic test was done on the command line API, which works correctly. It’s likely the problem here is they created a separate StorageKit API just for Disk Utility to use and got sloppy with the unit test for that. A good example of why it is a good idea to try to have GUIs and command lines use one code path whenever possible.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#74

Post by vbezhenar » Mon, Oct 09, 2017, 12:27 PM UTC

Why they are duplicating StorageKit code? If diskutil was using StorageKit, it's more likely that someone would find this bug (because apparently everyone in Apple uses diskutil instead of GUI).

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#75

Post by tonyedgecombe » Mon, Oct 09, 2017, 12:31 PM UTC

rusk wrote: post #24

danra wrote: post #16

It's pretty insane this sort of bug either passed or didn't even go through code review and testing at Apple, a company which has approximately infinite resources and whose marketing pitch is making high-quality products. I loved Apple products and still do, but as both a user of and a developer for their systems, I feel the quality has been steadily going downhill the last few years.

> whose marketing pitch is making high-quality products "It just works" was retired some time ago. "Think different" is the modern day mantra. It's less of an open-ended commitment.

It's less of an open-ended commitment.

Biting.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#76

Post by rangibaby » Mon, Oct 09, 2017, 12:31 PM UTC

veidr wrote: post #71

danra wrote: post #16

It's pretty insane this sort of bug either passed or didn't even go through code review and testing at Apple, a company which has approximately infinite resources and whose marketing pitch is making high-quality products. I loved Apple products and still do, but as both a user of and a developer for their systems, I feel the quality has been steadily going downhill the last few years.

I think you might be looking at the past through rose-colored glasses. Apple's always had horrible show-stopping bugs, in every single OS X / macOS release[1], from when simple operations like updating iTunes or enabling the OS's Guest Mode might delete your home directories, to this latest failure. I suspect one reason is that they like one-person teams so much. I like one-person projects too! But there is always pa…

> EDIT: except maybe Mac OS X 10.6? Does anybody remember any critical bugs in that one? I think that might be the unicorn.

Google "10.6.0 font problems", this caused a major headache at my work

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#77

Post by throwanem » Mon, Oct 09, 2017, 12:33 PM UTC

auggierose wrote: post #69

danra wrote: post #16

It's pretty insane this sort of bug either passed or didn't even go through code review and testing at Apple, a company which has approximately infinite resources and whose marketing pitch is making high-quality products. I loved Apple products and still do, but as both a user of and a developer for their systems, I feel the quality has been steadily going downhill the last few years.

The problem with testing is that it has the potential to gobble up infinite resources without actually adding much value. Just because you tested something, doesn't mean it will work reliably. It's that simple.

No, but if your tests are good, they'll catch bugs and especially regressions that would otherwise make it to production. Of course there's a balance to be struck, but it's approximately as sensible to devote zero resources here as infinite.

On the other hand, good review would much more likely have caught a bug like this than good tests would. "Why are you passing the password as the password hint?" Simple as that.

Again, there's a balance to be struck, and I don't claim code review is a panacea. But I do think it's a very worthwhile, and in the general case necessary, part of an engineering culture strongly oriented toward reliability.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#78

Post by tonyedgecombe » Mon, Oct 09, 2017, 12:34 PM UTC

cjsuk wrote: post #57

tempodox wrote: post #20

Installing a new Mac OS on a machine you care for has become an absolute no-go area. I wait for at least half a year and then only install in a place that I can trash in case I still see problems.

Let us not forget the butt clench of doom from Microsoft either. Every minor updates hoses people these days as well.

Half the problem with MS now is not the bugs, it's working as designed, it's the design that's the problem.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#79

Post by caseymarquis » Mon, Oct 09, 2017, 12:37 PM UTC

saagarjha wrote: post #8

IncRnd wrote: post #4

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; /* MISTAKE! THIS LINE SHOULD NOT BE HERE */ if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; History repeats itself in ever stranger ways. While the effects are different, the original mistake can be quite similar.

This is the SSL bug from iOS 9 for those wondering.

Neat that the textbook justification for Python whitespace syntax over curly brace syntax has caused serious real world bugs.

Re: Reverse Engineering MacOS High Sierra Supplemental Update

#80

Post by abalone » Mon, Oct 09, 2017, 12:39 PM UTC

So the lesson here is, it’s a good idea to try to have your GUI and command line use the same code paths. Looks like they created a separate API in StorageKit just for Disk Utility and got sloppy with unit test.