Hacker News Reader

Comment by ris | Hacker News Reader

How is this significantly different from shipping java/dalvik/whatever bytecode?

The real issue is who gets to sign the code. Formerly, you could sign the code yourself, so the cryptographic "chain of custody" between you and your users would be preserved. Now, since Apple generates the code that users see, you can't check and sign it. Apple can sign it, somebody who has compromised Apple's infrastructure can sign it, but you can't (unless you're the one who compromised their infrastructure). So, basically, this is a giant MITM just waiting to be exploited.

That's not new though, Apple is the one signing the apps on the store from its launch.

True, but what is now a mutable choice becomes less so when the technology involved doesn't support any other option. Their approach also precludes a second signature embedded and checked within the app itself, independent of the app-store signature.

Apple already re-signs all apps sent through the App Store. That plus Fairplay encryption makes it unnecessarily difficult for end recipients to verify the chain of custody for the code.

I don't quite get why Xcode couldn't generate both the LLVM bitcode + the fat binary for all architectures, along with any flags. Then Apple could regenerate the same binary (to verify the two match) but use the bitcode for their program analysis tools. Then, the developer's signature could be left intact on the binary and Apple would add an additional signature over the whole thing that indicated it was approved for distribution via the App Store.

Because Apple explicitly wants to be able to regenerate binaries from the bitcode, which means that any locally-generated binary is meaningless. The claimed reason for this is to take advantage of new optimizations added to LLVM (which is a perfectly sensible thing to take advantage of), but probably the more useful reason is to take advantage of new microarchitectures that Apple introduces in new devices.

Yes, this is the real thing that should be debated -- where does the developer's responsibility end and the App Store's begin?

If I created an app, both distributed internally (say, to my corporate users) and via the App Store, but the App Store version has a bug because they're using a different ARM backend than my Xcode, that will be a real pain to debug.

Translating bitcode to binary must be done by open-source tool (llvm?) and bitcode must be available for end-user. Then end-user can download bitcode, download llvm, translate bitcode and compare it to the binary he got from AppStore. But it unlikely to happen, because this feature would be hard to sell.

It's not significantly different, although iOS hasn't had bytecode before.

One thing that is different is that there's no transparency into the process. If your Java code is crashing, you can look at the code the JIT is generating. If your Java code is only crashing on certain hardware or OS revisions or whatever, you can see what's different about the JIT in those circumstances and at least make an attempt to investigate. With Apple's system, you have no idea what compiler version they're running, when they make changes, what machine code your users end up running, etc.

java/dalvik/whatever bytecode is simple, has a clear formal specification, and is not vulnerable to the same scale of "undefined behavior" traps that you'll find in C/C++ and LLVM IR.

Reply on news.ycombinator.com