MAS Publish Error: Invalid Code Signing ... must be signed with the certificate that is contained in the provisioning profile

[semireg]

• Electron-Builder Version: 23.1.0 - 23.3.2
• Node Version: 14.17.0
• Electron Version: 18.3.2
• Electron Type (current, beta, nightly): current
• Target: --universal (Mac x64 and arm64)

Happy to report that I have a working Universal (fat) app for non-MAS builds.

However, there's some kind of MAS-related code-signing issue happening, possibly related to x64ArchFiles. Here's what I'm seeing on MAS publish for both thin/fat apps:

2022-07-21 21:30:48.405 *** Error: Invalid Code Signing. The executable 'com.semireg.LabelLIVE.pkg/Payload/Label LIVE.app/Contents/Frameworks/numbers-to-csv/Python' must be signed with the certificate that is contained in the provisioning profile. With error code STATE_ERROR.VALIDATION_ERROR.90284 for id ABCD-1234-DEFGH-5678 Asset validation failed (-19208)

I only get this when using the latest electron-builder >= 23.3.0.

Could it be related to copying numbers-to-csv over in a extraFiles/extraResources step? I've checked the offending file and nothing stands out as obviously wrong, but I'm no expert in MAS code signing.

Sometimes I see a failure at build/package/signing time. For example, this strange output with 23.2.0 which seems related somehow...

⨯ Command failed: codesign --sign ABCD1234EFGHIJKLMNOPQ --force --timestamp --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --options runtime --entitlements build/entitlements-lll.plist /Users/path/release/mas/Label LIVE.app/Contents/Frameworks/numbers-to-csv/Python /Users/path/release/mas/Label LIVE.app/Contents/Frameworks/numbers-to-csv/Python: replacing existing signature /Users/path/release/mas/Label LIVE.app/Contents/Frameworks/numbers-to-csv/Python: main executable failed strict validation

Maybe a clue? 🤷

Fwiw, downgrading to 23.1.0 lets me build/upload a standard/thin x86 MAS app, however, it can't successfully build/upload a Universal (fat) app due to the above Code Signing rejection when publishing to MAS.

[mmaietta]

Hey @semireg, I'm trying out a potential fix, not sure how well it'll work but all CI builds pass. Please try 23.3.3 when it publishes momentarily.

[semireg]

@mmaietta, not yet seeing the new version.

[mmaietta]

I've already been using it since yesterday. It's on npm.
https://www.npmjs.com/package/electron-builder?activeTab=versions

[semireg]

Ah, @next. Gotcha. I was using @latest.

Here's what I get without updating the @electron/universal's node_modules/app-builder-lib to @latest:

fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: /private/var/folders/pn/0_zc5fx96_z046tylfv1j6gw0000gn/T/electron-universal-qUlo7z/Tmp.app/Contents/Frameworks/numbers-to-csv/Python and /path/to/mas-universal--arm64/Label LIVE.app/Contents/Frameworks/numbers-to-csv/Python have the same architectures (x86_64) and can't be in the same fat output file failedTask=build stackTrace=Error: Command failed with a non-zero return code (1):

My "fix" is described at #5891 (comment). Is it intentional to use that older version of @electron/universal?

I'm still getting the same MAS upload rejection error as before. I went through and double-checked my provisioning profile, certs, etc. I can't find anything out of place... and it's strange that the thin build with 23.1.0 uploads to MAS just fine. 😢

[semireg]

Another thing I noticed. I see it copying files from mac.extraFiles and mas.extraFiles, but in my case, I only want the mas files copied.

    "mac": {
....
      "extraFiles": [
        {
          "from": "external/numbers-to-csv-mac/Frameworks/",
          "to": "Frameworks/"
        }
      ],
      "extraResources": [
        {
          "from": "external/numbers-to-csv-mac/Resources/"
        }
      ],
      "x64ArchFiles": "Contents/Frameworks/numbers-to-csv/{numbers-to-csv,Python,*.dylib,google/_upb/*.so,lib-dynload/*.so,/snappy/*.so}",
      "mergeASARs": false
    },

then...

    "mas": {
      "hardenedRuntime": false,
      "provisioningProfile": "build/mas2022.provisionprofile",
      "entitlements": "build/entitlements-sandbox.plist",
      "entitlementsInherit": "build/entitlements-inherit.plist",
      "extraFiles": [
        {
          "from": "external/numbers-to-csv-mas/Frameworks/",
          "to": "Frameworks/"
        }
      ],
      "extraResources": [
        {
          "from": "external/numbers-to-csv-mas/Resources/"
        }
      ]
    },

But it looks like it's copying both files, and possibly creating a race condition. I just checked and it seems like every-other build results in "... numbers-to-csv/Python have the same architectures (x86_64) and can't be in the same fat output file."

I'm so confused by --universal

[semireg]

I think I may have figured out the issue. But I don't have a definitive answer, just an anecdote. Sometime in the last year apple came out with a new kind of certificate plainly called "Distribution" which is for Xcode >11 and "ALL" platforms. Previously, we had different certs for "3rd Party Mac Developer Application" and maybe an "... Installer" version of this cert.

I know that the provisioningProfile is for this, which is set to "Distribution"...

Yet, output of spctl -vvv --raw --assess --type exec path/to/Label\ LIVE.app would show "origin=3rd Party..."

I went into my Keychain and deleted all certs starting with "3rd Party Mac" and packaged.

Now the output showed origin=Apple Distribution...

And behold, MAS upload works.

No errors uploading 'release/mas-universal/Label-LIVE-2.8.0-20800000.pkg'

[mmaietta]

Very interesting indeed.
I think that may be due to this line? It's defaulting to 3rd Party

electron-builder/packages/app-builder-lib/src/macPackager.ts

Line 471 in 28c07b4

return isMas ? ["3rd Party Mac Developer Application", "Apple Distribution"] : ["Developer ID Application"]

[semireg]

I don't know... and I fear weighing in too much and affecting other working installs. I'm curious, what is the associated behavior of the array? Does it sign with all, or is that the order in which they resolve? Perhaps "Apple Distribution" should come first? Again... I've been burned so hard by code signing that I'm scared to make any kind of conclusion either way. 🧯

[mmaietta]

I've been burned so hard by code signing that I'm scared to make any kind of conclusion either way.

Haha, I'm in the same situation. Since Apple Distribution is newer, maybe having it first would be appropriate. We could alter the order of it and see if anyone reports. I see multiple commits on that specific line and originally it was only Apple Distribution.

[mmaietta]

Published 23.3.3 as latest

[semireg]

Just a note (likely to myself) that failed strict validation can occur when a binary such as Python is checked into git as text vs. binary (wrong .gitattributes, correct: Python binary). To fix, you must replace the binary.

Using codesign -vvv --deep --strict FILENAME I was seeing invalid or unsupported format for signature which to me meant corruption of the binary.