Unable to sign x.app file

[junmaqiang]

①The compiled file under the Apple system is x.app. When signing, it prompts that the directory cannot be signed.

②## Should we also add zip and rar decompression processes?

[andydotxyz]

Please add more information. This library does work, and is tested regularly, with macOS.

[Bluebugs]

I am guessing from the message that he is trying to sign a directory and not the application binary itself.

[junmaqiang]

@Bluebugs yes you are very smart

I don’t know how to use the selfupdate function in an .app developed with fyne

[mottle-ai]

I have the same question.

I'm uploading a mac update to my cloud bucket - and executable that was previously code signed and part of a bundle notarized by Apple: AppName-darwin-amd64

This is effectively this file: AppName.app/Contents/MacOS/AppName, just renamed

Selfupdate detects this new version from the cloud, and downloads it, but nothing happens.

When I inspect AppName.app/Contents/MacOS/AppName, it hasn't been updated. (Updated timestamp still the same.)

Surely some kind of security issue going on, probably with code signatures etc relating to the old master .app.

Is this supposed to work, or is this only for apps that aren't doin the whole code signature / notarization rigmarole ....?

Note, I've given the app com.apple.security.automation.apple-events entitlements, as I saw an error relating to this that looked related. Didn't solve the problem.

I now see the following error in the logs:

RBSStateCapture remove item called for untracked item <numbers removed> (target:[app<application.com.app.AppName.<more numbers removed>(501)>:23687])

[Bluebugs]

@mottle-ai It will be useful if you could set the 3 functions provided for logging in the package: LogDebug, LogInfo and LogError ( https://pkg.go.dev/github.com/fynelabs/selfupdate?utm_source=godoc#LogDebug ) and see what the logs are saying.

[mottle-ai]

Thanks for the fast reply!

This is the error I get:

2024/01/26 16:36:28 Upgrade error: open /Applications/AppName.app/Contents/MacOS/.AppName.new: permission denied

I assume this has something to do with the hardened runtime?
https://developer.apple.com/documentation/security/updating_mac_software

[Bluebugs]

We actually already do a rename as described in the documentation. Is it possible that the application was installed by a different user and that you do not have the right to alter it?

[ruianderson]

@Bluebugs any way you think we could patch the process to replace the .app instead of only the executable?

I saw electron updater and it uses Squirrel.Mac and when the app is installed it will download the new .app in a zip file, do the checks and finally replace the package within ~/Applications folder

[Bluebugs]

@Bluebugs any way you think we could patch the process to replace the .app instead of only the executable?

I saw electron updater and it uses Squirrel.Mac and when the app is installed it will download the new .app in a zip file, do the checks and finally replace the package within ~/Applications folder

This is a good question. I don't have currently a good answer. My main concern is how do you get this to fit with something like tuf. Do you need to with zip and ship the entire package, or is it best to have per file update mechanism or should we bring in binary diff update.

I think we should move this part of the discussion to it own issue to figure out what we want to do for application package delivery, on what platform and for what purpose.

[mottle-ai]

Just a quick update: I was able to change the way I install the pkg so that I can install as the user, not as root (using a postinstall script). That solves the permission issue, and the update is applied. However, now the application then won't restart because of course the code signature checks fail.
It would be amazing if a single .zip containing the new .app could be downloaded, and the entire .app replaced...

[Bluebugs]

So apple signature is not applied on the binary, but only in the .app/zip file?

[mottle-ai]

Yes, MacOS apps is basically a little directory structure that looks like a single executable file.
You can see here that, after the update, the MacOS directory has been updated -- this is where the binary is kept -- but the _CodeSignature directory has not been updated with the new signature.
When I run pkgutil --check-signature AppName.app the signature is invalid

[Bluebugs]

Following https://servicemax.com.au/tips/signing-and-notarising-a-mac-binary-written-in-go/ could you try signing just the binary?

[mottle-ai]

Following https://servicemax.com.au/tips/signing-and-notarising-a-mac-binary-written-in-go/ could you try signing just the binary?

Yes, this is what I already do. My build file looks very similar to this ...

I suspect though, if you patch in a binary to an .app that's been signed previously, you break the signature on the .app? (tbh, I'm not sure.)

[Bluebugs]

That link describe two signature method. One for the bundle (.app) and one for the binary itself. I am thinking, but haven't tried, that once a binary is signed (but not the bundle, as it is optional), it should be OK to use it for update. It means that existing installation can't be updated if the bundle is signed, but should if just the binary is and the binary is also signed.