Notarization "success" with a warning of lacking password for encrypted zip archive, then the GateKeeper rejects app

Does your password-protected zip archive contain any code?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I suspect the .zip is not to blame. I know of at least one app that contains an encrypted .zip file, and it gets through Gatekeeper fine. (Unless the rules have changed very recently.)

Thanks for reply, eskimo.

I found some garbage shell script files in my zip archive, which I used for making some resouces easily...

Removed all the sh files and Pixelmator pxd files, etc... then remaining files in the archive are below:

.bmp

.tif

.png

.mp3

and below is my custom extension

.ro1 (text)

.ro2 (text)

.rvb (text)

.rm0 (text)

.rm1 (text)

.ri0 (non executable binary image file)

Removed executable sh files and then re-zipped and notalized the app.

Result are the same...

In the warning of notarization, says

"no password provided for encrypted PKZip archive"

so is there a way to provide the password for the zip in notarization process?

Thanks for reply.

Might something be wrong other than the enctypted zip...?

Oops, I tried removing the zip archive entirely from the app and notarized it then the GateKeeper still says "the identity of the developer cannot be confirmed."

So it was not the problem of the password zipped archive...

Something is wrong...

Thanks.

SOLVED:

I looked into Console.app, then found a message com.apple.xprotect failed on rPathCmd

on some dylibs included in my App.

I modified dylibs' @rpathes to @executable_path/../Frameworks/..

Notalized and uploaded to my web server, then download and open it to found the GateKeeper never blocks it.

It was totally dylib's @rpath problem.

Thanks!

It was totally dylib's @rpath problem.

Glad you got this sorted out.

I also want to explain the background to my question. The notary service must be able to ‘see’ all the code in your product [1] so that it can include that code in the ticket that it issues. If you product has an encrypted zip archive, the notary service can’t see inside that. If that archive contains any code, that’d be bad, because that code wouldn’t be include included in the ticket. However, if that archive just contains data, it’s fine to ignore this warning.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Here code means native code, that is, Mach-O images. Scripts areh not considered code in the context of code signing.

The notary service can't see inside encryped zip archives, I see.

What will happen in notarization process in case any (native) codes included in the encrypted archive?

The notary service claims an error? or just an warning?

And, in case the notary service claims just an warning,

will the GateKeeper save us from possible malicious native codes in the archive?

This time I included only data in the archive.

Thanks so much for this info.

I ran into this warning when including a password protected zip of JXA (JavaScript for Automation) source code, which I did becuase there is no way to export JXA as Run-Only like you can with regular AppleScript and I didn't want to release the source of my applet.

While I'm glad this only produced a warning and still allowed Notarization, is it true that Notarization doesn't care about zipped and password protected script source files such as bash or python or JXA or any other "scripting" lanugage?

This seems a bit odd when any scripting language could call native code or any powerful bash commands and theoretically do any malicious thing it wants without Apple being able to review the source files during Notarization.

But are you saying that Notarization doesn't even analyze the source of scripts anyways because "scripts are not considered code in the context of code signing"?

If scripts are in fact analyzed (and even if not) it seems like there should be way to be able to provide Apple with zip passwords so all included app files can be analyzed during Notarization while also not forcing developers to expose the source to the end-users.