GateKeeper rejects application bundles with a file name with an NFC/NFD problem by copying with Finder

Question

Created 3w

Replies 5

Boosts 1

Participants 2

I made a macOS application using Swift Package and distributed it in dmg format through Apple Notary service. However, we received a report from a user that it can be launched from a disk image mounted from dmg, but when copied to /Applications, the app is broken and does not start.

I looked into why this happened, I noticed that the codesign command returned different results when copying the application bundle and /Applications on the volume mounted dmg with Finder.

Mounted dmg: OK

❯ codesign --verify --deep --verbose /Volumes/azoo-key-skkserv/azoo-key-skkserv.app
/Volumes/azoo-key-skkserv/azoo-key-skkserv.app: valid on disk
/Volumes/azoo-key-skkserv/azoo-key-skkserv.app: satisfies its Designated Requirement

Copied by Finder: Bad

codesign reports that there are 148 added/missing files.

❯ codesign --verify --deep --verbose /Applications/azoo-key-skkserv.app
/Applications/azoo-key-skkserv.app: a sealed resource is missing or invalid
file added: /Applications/azoo-key-skkserv.app/Contents/Resources/AzooKeyKanakanjiConverter_KanaKanjiConverterModuleWithDefaultDictionary.bundle/Contents/Resources/Dictionary/louds/グ1.loudstxt3
(skip...)
file missing: /Applications/azoo-key-skkserv.app/Contents/Resources/AzooKeyKanakanjiConverter_KanaKanjiConverterModuleWithDefaultDictionary.bundle/Contents/Resources/Dictionary/louds/グ1.loudstxt3
(skip...)

Copied by ditto: OK

❯ ditto /Volumes/azoo-key-skkserv/azoo-key-skkserv.app /Applications/azoo-key-skkserv.app

❯ codesign --verify --deep --verbose /Applications/azoo-key-skkserv.app
/Applications/azoo-key-skkserv.app: valid on disk
/Applications/azoo-key-skkserv.app: satisfies its Designated Requirement

I made a simple macOS application to explain this problem in an easy-to-understand way. You can download dmg in github releases, mount dmg, copy it in the Finder, and check if there is a problem by running the codesign command.

https://github.com/mtgto/example-utf8-mac-notarization

As a result, I learned the following two things.

Occurs only with resources with file names whose values change due to NFC/NFD normalization
No problems occur with the resources of the application itself. Generated by the Swift Package resources that the application depends on

I think this is a problem with Finder or Gatekeeper.

Answered by DTS Engineer in 853064022

I think this is a problem with Finder or Gatekeeper.

And you are correct. This is a long-standing issue with the code signing subsystem. See my explanation here.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

3w

Accepted Answer

Recommended

I think this is a problem with Finder or Gatekeeper.

And you are correct. This is a long-standing issue with the code signing subsystem. See my explanation here.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

mtgto OP

3w

Thank you for your reply.

This is really confusing, so please fix it quickly. I avoided this problem by distributing it in pkg format for now.

0

Answer 3

DTS Engineer OP

Apple

3w

I avoided this problem by distributing it in pkg format for now.

That might work in some cases, but it’s not the fix I recommend.

There are lots of things that could potentially change the normalisation, and hence break the seal of any code signature. For example, the user might AirDrop it to their other Mac, or update their Mac using Migration Assistant, or copy it in the Finder, or zip and then unzip it. You can’t possibly test all of these cases and, even if you could, there’s no guarantee that things won’t change on a future system.

The fix I recommend is to use ASCII file names within your bundle. This is always going to work. And yes, making that change is annoying, but it’s an annoyance you have to deal with once. Your current approach might require you to revisit this issue again at some point in the future.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

mtgto OP

3w

The fix I recommend is to use ASCII file names within your bundle. This is always going to work.

It is not my source code that has non-ASCII file names, but the library I am using, so it is not easy to fix.

0

Answer 5

DTS Engineer OP

Apple

3w

OK. In that case I recommend that you forward my advice on to the library’s author. Their use of non-ASCII file names is going to cause problems for anyone adopting their library on macOS, so it makes sense for them to fix it in one place.

And, just to be clear, I really wish I could say that a fix for (r. 68829319) was imminent, but I can’t. I’m unable predict the future, but I think it’s reasonable to choose your path based on past experience. And in this case:

This bug has existed since code signing was first introduced back in macOS 10.6.
The above-mentioned bug report was filed in 2020.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0