It depends. If you can add metadata to the bundle without it being detected (a problem that has cropped up with Linux repositories several times) then this is a genuine vuln. If OTOH it's something like "If you install a Python interpreter then you can use that to run arbitrary code that isn't validated by Gatekeeper" then it's a "Code execution results in code execution" issue. In the great tradition of journalists everywhere, the ThreatPost article never provided any links to any original material, so all we have is the writer's interpretation of what's actually going on,

Assuming the previous reply was by the guy who gave the talk, is it online anywhere?

It does sound and awful lot like the notorious MS07-052: Code execution results in code execution

.

Of course it doesn't, everyone knows that! You cure cancer, and in particular pancreatic cancer, with a strict vegan diet, acupuncture sessions, drinking special fruit juices, hydrotherapy, and visiting spiritualists.

Well that's not quite correct, while Windows XP may merely suck dick, iTunes actually swallows.

That's "African-American op", you insensitive clod! If Bush had done it you'd probably be calling it a white op.

Nope. Quoting from TFA

So you still get SuperPhished, only now it's DeviceGuarded.

How would that differ from current practice, at least in Hollywood? No film franchise is complete until it's had at least two or three shit sequels.

It's sometimes correct. When it's not correct, your bug report that it (for example) produces code that segfaults with -O3 on x86-64 is closed as "by design" because if you stare at the manpage long enough while drunk it could be interpreted as being allowable behaviour under certain circumstances and therefore doesn't need to be fixed.

That was my reaction too. "Latest update of bug-ridden, bloated alternative to LLVM released".

(And no, I couldn't give a toss about Apple, I just want a compiler where, for each new release, I don't have to spend a long-tail of several months identifying new compiler bugs and design "features" and adding code workarounds to deal with them).

a.k.a. "agar dishes for childhood diseases".

Uh, yeah, that was an issue for Windows 3.1 more than twenty years ago. There have been a few advances in dealing with this since then. Using Windows 3.1 engineering issues as an excuse for current bad engineering issues doesn't really cut it.

Good point. I mean, arguing over who has the biggest di..phone and resolving the issue with broken bottles is kinda wimpy, nothing like the real arguments we had about serious issues like whether the Amiga was better than the Atari ST, which often came close to armed conflict. I mean, I personally beat some idiot to death with a VIC20 for suggesting that his Commie 64 was better than my IIgs. Now those were real arguments, none of this cellphone woosiness there.

That pretty much sums it up in one line (I can't moderate a discussion that I'm part of or you'd get a +1 Insightful).

But the thing about the cellular network is that it's incredibly resilient. Some years ago we had a major earthquake here that wiped out significant chunks of a city and the surrounding area. No power, no water, nothing. The cellular network partially functioned (on banks of lead-acid batteries at many cell sites) until crews got generators in as a priority (which included, among other things, competing cellphone providers servicing and powering each others' gear), and cellphones themselves were battery powered and kept going while (mostly) mains-powered radio receivers went silent. So the cellular network, while overloaded due to the scale of the disaster, continued to provide service. For the subset of radio stations that were still operating, very few people were able to listen.