In need of a sample receipt file that uses the SHA-256 hash

Question

Created 7h

Replies 3

Boosts 0

Participants 1

My app that's been around since the dawn of the Mac App Store, and which uses its own receipt validation code for 15 years now, recently sometimes triggers a "does not support the latest receipt validation requirements" error message with my app's users.

But I cannot reproduce it, even if I freshly install the app on a M4 Mac running macOS 26.2.

So I have a hard time testing my fix.

Does someone have a sample receipt file they could share with me (including the MAC from "en0" / GUID device ID), or do you know where I can find one that uses the new SHA-256 hash?

In fact - when reading https://developer.apple.com/documentation/appstorereceipts/validating-receipts-on-the-device it seems that there's only a SHA-1 after all. So why do some users get the "receipt validation requirements" message at all? I'm only reading the receipt, decoding the ASN.1 fields and then validate the hash from the receipt (field 5) against the SHA-1 from the GUID+receipt, as always, calling libCrypto's SHA1() function. So, what would even trigger the message, as I'm not invoking any higher-level APIs that would verify the receipt for me, and thus would know when something is wrong?!?

Answered by Thomas Tempelmann in 870794022

Ahh, finally found the right answer here: https://github.com/iterate-ch/cyberduck/issues/16031

Basically, the default behavior of hiding the actual Mac's MAC address is the cause for the problem ("Privaty Wi-Fi Address"):

If the Mac rotates or replaces the primary network interface's MAC address, and my code still uses the old code that would fetch the MAC from the higher level APIs, it would get the wrong MAC, and then fail the receipt check.

To fix this, the MAC has to be fetched from IOKit registry, e.g. as shown in https://developer.apple.com/documentation/appstorereceipts/validating-receipts-on-the-device or https://lapcatsoftware.com/articles/2023/11/4.html

Boost

Answer 1

Thomas Tempelmann OP

4h

I can't seem to edit the message now that I know a bit more. So, here's a reply instead.

Turns out that the basic receipt validation does not use SHA-256.
The message rather seems to come up when my app quits with exit code 173 due to the receipt being invalid (as in when the app was copied from a different Mac, and now the GUID doesn't match).
Whereas older macOS versions would then re-fetch a new receipt (and optionally ask the user to authenticate again), this doesn't apparently happen any more (WhyTF not? Why not keep the old method and only use the new method when the app makes it known to support the new method?!)
Forcing a re-fetch of the receipt by simply deleting and re-installing the app from the MAS doesn't appear to work either as the receipt appears to be cached somewhere (again WTF - why isn't macOS being cautious here and falls back to downloading it when the app keeps returning 173???)
It appears the app now has to explicitly request a new receipt. With SKReceiptRefreshRequest, which is already deprecated, but no alternative is offered (I don't do in-app purchases and also don't use Xcode/Swift but something different that doesn't offer access to these classes).

Searching for the error message turned up other reports where people ran into this problem with old programs that cannot be launched any more just because of this receipt caching that apparently doesn't fix itself. I can't understand why macOS is handling this so badly. Is that just ignorance or thoughtlessness on behalf of the responsible dev team at Apple or is there some good reason why macOS can't give older apps and their long-time users a break here?

Or me, who has to spend hours to keep the app working just to keep up with such changes (another one is that suddenly in Tahoe right-clicks into the menu bar item don't register any more if the mouse is at the top edge of the menu bat - which totally violates basic UI concepts established over 40 years ago). This year isn't going well so far for me.

0

Answer 2

Thomas Tempelmann OP

2h

This is getting worse - a person who gets this error sent me the receipt file, and it turns out that the receipt file is fine, meaning that the validation shouldn't even fail, and thus the app not exit with 173. And since my app doesn't use any in-app purchases either, I'm now clueless what's actually causing this.

In other words: What exactly causes this message to appear?

0

Answer 3

Thomas Tempelmann OP

2h

Accepted Answer

Ahh, finally found the right answer here: https://github.com/iterate-ch/cyberduck/issues/16031

Basically, the default behavior of hiding the actual Mac's MAC address is the cause for the problem ("Privaty Wi-Fi Address"):

If the Mac rotates or replaces the primary network interface's MAC address, and my code still uses the old code that would fetch the MAC from the higher level APIs, it would get the wrong MAC, and then fail the receipt check.

To fix this, the MAC has to be fetched from IOKit registry, e.g. as shown in https://developer.apple.com/documentation/appstorereceipts/validating-receipts-on-the-device or https://lapcatsoftware.com/articles/2023/11/4.html

0