XPost: misc.phone.mobile.iphone, comp.sys.mac.system

On Thu, 13 Jan 2022 09:59:43 -0500, nospam wrote:

because having homekit device names longer than 500,000
characters is so incredibly common.

how could that have possibly slipped through??

FACTS:
1. The bug was _not_ found by Apple QA
2. The bug is a _classic_ (which means there is _no_ Apple QA to speak of!)
3. The bug was reported to Apple in the middle of last year
4. Apple refused to fix it in a timely manner (by _all_ accounts!)
5. Exasperated, researches made the bub public (after waiting half a year!)
6. Only then did Apple even _bother_ to fix this rather serious flaw.

ASSESSMENT:
*Apple only fixes known security bugs well _after_ the shit hits the fan!*

I realize you make excuses for Apple no matter what, but the fact remains
that an overflow (such as the classic buffer overflow) is not only easy to predict but it's also one of the _first things_ a decent QA team tests for.

While even the head of engineering said Apple's QA is atrocious in an
internal memo (which we've discussed in the past), it's _trivial_ to test
for buffer overflows.

They just didn't bother to test even this, the _simplest_ of expected tests.

it should have been the first thing to test.

for reference, 500,000 characters is roughly 1000 *pages* of
single-spaced text, which would take nearly 17 continuous hours to
type, assuming a sustained 100 wpm for the entire time, without any
breaks for food, bathroom or anything else.

Again, you'll excuse every Apple flaw, where now you claim computers can't
add one repetitively to any buffer QA test (which is patently ridiculous).

What you fail to comprehend in your quest to defend even this huge Apple QA flaw is the following accurate observation in the aforementioned reference:
"'*I believe this bug is being handled inappropriately*
as it poses a serious risk to users
and many months have passed without a comprehensive fix' Spiniolas said.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)