Binary is improperly signed but the copy is ok

Question

Helloworld21Centry OP

Created Sep ’21

Replies 3

Boosts 0

Participants 2

Hi there,

We are developing an applicaton that can update itself.

For example, we have two version 1 & 2. Both of them are signed, notarlized and stapled mac app bundle. When the version 1 find that there is a new version. It would download the difference. Then open another application named updater we developed. The updater use some posix function such as fopen, fwrite, chmod and link to copy/delete files to make the original one as the same as the version 2.

The problem comes out here. When we open the updated one, the syslog says that binary is improperly signed. I don't know which step is incorrect. I make a copy of this app, it works perfectly.

I guess there is something wrong with the application updater. We tried make the updater to be a single executable file or an signed, notarlized and stapled application bundle and still not work. After read some threads I still could not find out what is it.

Hope someone could help me about this.

Thanks in advance!

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’21

The updater use some posix function such as fopen, fwrite, chmod and link to copy/delete files to make the original one as the same as the version 2.

This is fine for most files but you will run into problem if you do this for Mach-O images, that is, your app’s main executable, or any shared libraries, or the executable files within a framework or bundle. See this thread for more.

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

0

Answer 2

DTS Engineer OP

Apple

Sep ’21

I cannot open the link you provided

Oh, blat! That post is in an area of DevForums that’s restricted to folks who participated in the DTK programme. However, there’s nothing DTK-specific about this, or even Apple silicon specific, so I’m happy to repost it here:

OK, based on this, and some info I saw internally, I think you’re hitting a known oddity in macOS’s code signing subsystem. The kernel caches code signature information from a Mach-O image file and does not flush that cache when you modify the underlying file. This can result in all sorts of odd behaviour. So, if you update a Mach-O image file on disk, it’s important to write the new image to a a new file and then replace the original file with that. Tools like cp and scp don’t do this, and thus are susceptible to this problem.

The new thing that I learnt today is that this codesign_allocate error can be a symptom of this failure. Most of the time when I see this problem it’s because the process has crashed with a mysterious code signature error on launch. I didn’t know that code signing operations can also be affected by this.

Sorry about the bum steer. And I’ve updated my records so that I won’t make this mistake again.

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

0

Answer 3

DTS Engineer OP

Apple

Oct ’21

I think you’re hitting a known oddity in macOS’s code signing subsystem.

I wrote a doc, Updating Mac Software, that covers this in more detail.

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

0