Notarization has stopped working for .pkg files

Question

adriangm20 OP

Created Oct ’19

Replies 12

Boosts 0

Views 2.2k

Participants 3

Hi,

Notarization of .pkg files has stopped working for me. Basically, the .pkg file is notarized but the contents are not. The notarization log shows the following response:

{
  "logFormatVersion": 1,
  "jobId": "[jobId-edited]",
  "status": "Accepted",
  "statusSummary": "Ready for distribution",
  "statusCode": 0,
  "archiveFilename": "WiFiExplorerPro_2.3.pkg",
  "uploadDate": "2019-10-25T22:34:38Z",
  "sha256": "[sha256-edited]",
  "ticketContents": [
  {
  "path": "WiFiExplorerPro_2.3.pkg",
  "digestAlgorithm": "SHA-1",
  "cdhash": "[cdhash-edited]"
  }
  ],
  "issues": [
  {
  "severity": "warning",
  "code": null,
  "path": "WiFiExplorerPro_2.3.pkg",
  "message": "This archive is corrupt, and cannot be unpacked for analysis.",
  "docUrl": null,
  "architecture": null
  }
  ]
}

The same packaging/notarization workflow was working for me two weeks ago but now it ends up with this error. Well, a warning, but the error comes later when trying to staple the .app inside the .pkg, since it wasn't notarized. As far as I know, nothing changed on my side, as I said, it's the same process to generate the .pkg and notarize it.

By the way, the .app can be notarized by itself, separately, so it's not an error when notarizing the .app. The .pkg file works fine, it can be launched, and passes all checks with regards to codesigning and notarization. Howerver, notarization is saying the archive is corrupt.

Are there any other log files produced by the notarization process that I can review?

Any hints on what could be wrong here?

Thanks,

Adrian

Answered by adriangm20 in 631163022

For what it's worth it, I ended up migrating the creation of the installers from PackageMaker to product build//pkgbuild (while using the same contents, resources, etc.), which I had to do anyway, and notarization works perfectly.

Boost

Answer 1

adriangm20 OP

Oct ’19

Just to add to the post, I tried notarizing again a .pkg installer that I had already notarized successfully a few weeks ago and I got the same problem, so unless I'm missing something obvious here, there was a change in Apple's side that is now causing this problem.

In the meantime, I'm going to try to notarize the app first, then package it, and then notarize the .pkg file.

0

Answer 2

DTS Engineer OP

Apple

Oct ’19

I’m not sure what’s going on in your specific situation but I tried notarising a package today and it worked as expected. Here’s what I did:

I created a dummy app from the macOS > App template.
I enabled the hardened runtime (I always forget that!).
I built an archive using Build > Archive.
In Xcode’s Organizer, I exported that as a Developer ID app.

I wrapped it in a package:

$ cat requirements.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict>     <key>home</key>     <true/> </dict> </plist> $ productbuild --product requirements.plist --sign "Developer ID Installer" --component Test125071.app /Applications Test125071.pkg

.

I submitted it for notarisation.

$ xcrun altool --notarize-app …credentials… --primary-bundle-id com.example.apple-samplecode.Test125071
No errors uploading 'Test125071.pkg'.
RequestUUID = 31552887-857a-400e-a32f-3dea770e18af

.

After a while the request was approved:

$ notarization-info 31552887-857a-400e-a32f-3dea770e18af
No errors getting notarization info.


      Date: 2019-10-31 09:45:26 +0000
      Hash: d643a8f12dea19b4ce0ba5f289758bc7d258d1bcc8d3fb39f598e97b29cac174
LogFileURL: … elided …
  RequestUUID: 31552887-857a-400e-a32f-3dea770e18af         Status: success   Status Code: 0 Status Message: Package Approved

.

I’m not sure why things are failing for you. My recommendation is that you run through the steps above. If that works, you know that the problem is related to your specific package and you can look at how its constructed. If it fails, it’s likely that there’s something about your environment that’s triggering the issue.

ps Here’s the log file URL that was elided above (DevForums got really grumpy when I included it in a code block).

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

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

0

Answer 3

adriangm20 OP

Nov ’19

Thank you!

I tried your steps and notarization worked as expected. I then went and tried the same steps but instead of packaging the test app, I packaged my app. It also worked. So, something about the way I'm building the package must be the reason for this to fail.

I was using PackageMaker (yes, I know) but when I started encountering this issue, I switched to Packages (a 3rd party app) for building the package (which I understand uses productbuild). The .pkg I'm creating is pretty much standard, except that it includes a couple of post-install scripts. I wonder if that's what's causing the problem. I'll have to play around with productbuild and see if I can find what exactly is making notarization report the package is corrupt. Or maybe if I use productbuild to construct the package the problem will go away.

Adrian

0

Answer 4

DTS Engineer OP

Apple

Nov ’19

I’m glad to hear you’re making progress. Please do let us know how things pan out. Whatever this problem turns out to be, I’m sure you won’t be the only person to have hit it.

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

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

0

Answer 5

LiquidSonics OP

Jan ’20

I started to experience this with installers made using PackageMaker and Packages and found the solution was to move from using RTF files over to plain text files for the installer's UI license and readme text sources. I used RTF previously to allow a little light formatting in the license shown to users, etc. Notarisation worked fully before signing the pkg, but after signing they would fail as described with a claim of a corrupt archive. Very peculiar problem needing baby-steps forwards to work out what the problematic delta from a basic working sample was, although this solution makes very little logical sense to me I figure it would be good to share what I did in case it helps somebody else.

0

Answer 6

DTS Engineer OP

Apple

Jan ’20

the solution was to move from using RTF files over to plain text files for the installer's UI license and readme text sources.

Did you RTF files end up having extended attributes on them?

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

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

0

Answer 7

LiquidSonics OP

Jan ’20

Yes. They're pretty simple files made in TextEdit. Checking against this list:

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/AttributedStrings/Tasks/RTFAndAttrStrings.html

The first line in one of the files is:

{\rtf1\ansi\ansicpg1252\cocoartf1504\cocoasubrtf810

I checked again and one of the files that had started failing to notarise has started working again, so I'm guessing something has been changed server side to resolve an issue here. Thanks.

0

Answer 8

DTS Engineer OP

Apple

Jan ’20

I’m not asking about the contents of the file, but rather any extended attributes. If you run

xattr

against the file, what does it show. Fro example, I created a simple RTF document using TextEdit and it has a world of extended attributes:

% xattr test.rtf 
com.apple.FinderInfo
com.apple.lastuseddate#PS
com.apple.macl
com.apple.metadata:_kMDItemUserTags
com.apple.metadata:kMDLabel_zz54gwvldkyjtoqpa42yxrazqa

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

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

0

Answer 9

LiquidSonics OP

Jan ’20

I found some installers not working still. Checked the xattr and yes, various, including some that had com.apple.quarantine which I guess could be causing a problem.

0

Answer 10

DTS Engineer OP

Apple

Jan ’20

Checked the xattr and yes, various

My general advice is that the contents of your installer package have no xattrs (except in the very rare circumstances where an xattr is absolutely required [1]).

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

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

[1] For example, when signing an Automator action.

0

Answer 11

LiquidSonics OP

Jan ’20

I pulled the extended attributes off the RTF files and it resolved it for one of the ones I was still failing to get through. Thanks.

0

Answer 12

adriangm20 OP

Sep ’20

Accepted Answer

For what it's worth it, I ended up migrating the creation of the installers from PackageMaker to product build//pkgbuild (while using the same contents, resources, etc.), which I had to do anyway, and notarization works perfectly.

0