Hacker News Reader

Comment by Daedren | Hacker News Reader

Apple's been automatically updating apps with these new signatures by themselves. You'll see changelogs with the following "This app has been updated by Apple to use the latest signing certificate."

I believe this is the case of an app that has been removed from the App Store though, which will receive no such support.

View on HN

Must have to do with Apple's change over time that you no longer submit the installable app to them for review, but an intermediate package with code and assets for multiple CPU architectures and screen resolutions; that means they can do the final packaging before installation. Smart.

wow. This means that there is no guarantee that the code I published is the code that gets installed. Does no one else have a problem with this?

App Thinning removes unused slices on download, it doesn't change compiled code.

But if you enable bitcode, that does involve the server recompiling your code for you.

Sure, but it's still your own LLVM IR that's being compiled, just on their end and not yours.

If you do not trust Apple, why are you wasting time writing apps for their platform?

I'm not a published app developer, but even if I don't trust Apple hundreds of millions of users do. If I wanted to market to those users, or if I worked for a company that wanted to, I would have to suck it up and deal with Apple and their platform in order to reach the users.

Not a useful question.

Also, trustworthy people do not ask you to trust them.

I am honest and trustworthy, and so if you gave me the pin to your debit card to go buy something for you, I would not mis-use that information.

But because I am honest, I would never ask you to trust me with your pin. If we were standing next to each other at a pos, I actively look away when you start to type so I don't even find it out by innocent accident.

Honest people take the trouble to figure out some way to get a job done without requiring you to trust them, even if you would have, even if it's less convenient for you both.

In fact, I think that one thing is probably the single biggest proof of trustworthiness.

A person or organization that I've never met before and and does not ask me to trust them, is more trustworthy than one that I've known for years and have a long history of good interactions with.

Apple could publish a builder binary with which you could verify that your submitted code gets compiled+linked+thinned into the same thing you get from the App Store (minus the signature.)

They haven't — which is bad — but they could, and that would be a guarantee. Same as you get with reproducible binary packages in Debian.

Many people have voiced exactly this problem.

And I would agree it should be outrageous and intolerable.

I wonder if there might be some way for a developer to post their own hashes somewhere, but then there's no good way for an end user to use them to verify their phone.

You could post a web page that reports that Apple has not modified the contents of your app, or a site could do that for many apps, by downloading the Apple-repacked app and checking it, but you could only check the copy of the app that the site downloaded.

It would not prove that Apple didn't modify the individual copy of the app residing on anyones phone.

I don't know the details of ios userspace, but I extremely doubt it's possible for the browser or any other app to read some other apps files and uload them to a site to have them checked. So you couldn't make a 3rd party site that says "check my phone".

Maybe such a report could be made by reading the app out of an unencrypted backup?

> I wonder if there might be some way for a developer to post their own hashes somewhere

Twitter, JSON/ATOM/RSS feeds, apps in privately hosted F-Droid compatible repos...etc

Oh, this is too good.

I mean, since Apple controls the entire OS there is already no guarantee that the code that gets installed is the code that gets executed. In other words, you already had that problem. (Of having to trust Apple in the first place.)

How is this different than when Google wants to do this? Because as far as I remember the consensus when the topic was last posted on HN was pretty clear that this was Google doing Bad Evil Things (as you have no guarantee that the code you submit is the code published).

On iOS, the security model has always been Apple signs the code, and no cryptographic protection from Apple modifying it.

On Android, the original security model was that the developer signs the code, preventing a distributor from modifying it (as long as the signature checks are sound).

Apple's system is worthy of complaining about, but you can only bring it up so often. Google taking Android backwards in this regard is worth making a fuss over; but Google is likely to just steamroll through.

I received an email from Apple regarding these updates, and posted it on SO looking for more information:

https://stackoverflow.com/questions/67067587/app-store-app-n...

I just checked the App Store for the first time since that update. The version number and release date remain the same. The only visible change is the new release text prepended with:

> This app has been updated by Apple to use the latest Apple signing certificate.

Yep. I received that in an email from Apple couple months ago for an old app I have on the store and since it had been working just fine for 3 years, I hadn't updated it. I decided to update it just in case the new signature would break something.

Link for those curious:

https://www.macrumors.com/2021/04/16/psa-apple-updating-old-...

Reply on news.ycombinator.com