4 ms·

I agree most of his concerns are not very relevant. The legitimate concern I see is verifiability of code custody from the developer to the end user. However, F

I agree most of his concerns are not very relevant. The legitimate concern I see is verifiability of code custody from the developer to the end user. However, Fairplay encryption of the exe means you have to dump the plaintext already in order to perform that step since the developer doesn't get to see it otherwise. I actually think it would be better if Xcode did both encryption and code-signing at the developer side, then Apple just added another signature on top of the full binary once it was approved for App Store distribution. This way, developers could easily verify that their signature was intact and that nothing had been modified in between.

eridius 11y ago
> The legitimate concern I see is verifiability of code custody from the developer to the end user Why is this a legitimate concern? I've never heard this even suggested as a remote possibility of a concern before. If you're already so paranoid as to suspect Apple of inserting malicious code into your application, it's a very tiny step to believing that they'd still serve you the original app and only serve the modified copy to certain targets, thus making any binary verification you can do meaningless. > I actually think it would be better if Xcode did both encryption and code-signing at the developer side Apple doesn't serve the same encrypted binary to everyone. Each user has an independent set of FairPlay keys and Apple serves up content encrypted for that particular user. That's kind of the whole point of FairPlay. If Apple served the same encrypted blob to everyone, then the encryption would be completely useless as everyone could decrypt it.
- nekitamo 11y ago
  > Apple doesn't serve the same encrypted binary to everyone. Each user has an independent set of FairPlay keys and Apple serves up content encrypted for that particular user. That's kind of the whole point of FairPlay. If Apple served the same encrypted blob to everyone, then the encryption would be completely useless as everyone could decrypt it. I used to think this as well. However, (my memory is fuzzy on this so take it with a grain of salt) a year ago I downloaded the same app from two different iTunes accounts. Both encrypted apps were identical, and had the same encrypted blob. So it seems Apple is not distributing a unique encrypted blob to each user, at least as far as apps are concerned.
- NateLawson 11y ago
  There's no need to trust Apple with re-signing the binary, it just happens to be implemented that way. It throws away the reason for the original code signature, which was for the developer to securely say "I created this." You could just upload unsigned binaries to the App Store in this case, saving a lot of complicated work with maintaining signing profiles. It's not that I don't trust Apple, it's that there's no reason to trust them in this case. Either stop forcing developers to deal with code signing for App Store apps or stop destroying their signature, allowing verification and logging of builds. And yes, the same encrypted binary IPA is served to everyone, but it gets customized by the device/iTunes.

eridius 11y ago

> The legitimate concern I see is verifiability of code custody from the developer to the end user Why is this a legitimate concern? I've never heard this even suggested as a remote possibility of a concern before. If you're already so paranoid as to suspect Apple of inserting malicious code into your application, it's a very tiny step to believing that they'd still serve you the original app and only serve the modified copy to certain targets, thus making any binary verification you can do meaningless. > I actually think it would be better if Xcode did both encryption and code-signing at the developer side Apple doesn't serve the same encrypted binary to everyone. Each user has an independent set of FairPlay keys and Apple serves up content encrypted for that particular user. That's kind of the whole point of FairPlay. If Apple served the same encrypted blob to everyone, then the encryption would be completely useless as everyone could decrypt it.

nekitamo 11y ago
> Apple doesn't serve the same encrypted binary to everyone. Each user has an independent set of FairPlay keys and Apple serves up content encrypted for that particular user. That's kind of the whole point of FairPlay. If Apple served the same encrypted blob to everyone, then the encryption would be completely useless as everyone could decrypt it. I used to think this as well. However, (my memory is fuzzy on this so take it with a grain of salt) a year ago I downloaded the same app from two different iTunes accounts. Both encrypted apps were identical, and had the same encrypted blob. So it seems Apple is not distributing a unique encrypted blob to each user, at least as far as apps are concerned.
NateLawson 11y ago
There's no need to trust Apple with re-signing the binary, it just happens to be implemented that way. It throws away the reason for the original code signature, which was for the developer to securely say "I created this." You could just upload unsigned binaries to the App Store in this case, saving a lot of complicated work with maintaining signing profiles. It's not that I don't trust Apple, it's that there's no reason to trust them in this case. Either stop forcing developers to deal with code signing for App Store apps or stop destroying their signature, allowing verification and logging of builds. And yes, the same encrypted binary IPA is served to everyone, but it gets customized by the device/iTunes.