Electron apps code-signed on OSX 10.11.4 do not verify on <= 10.11.3 #4899

Closed
mkscrg opened this Issue Mar 24, 2016 · 13 comments

Comments

Projects
None yet
8 participants
@mkscrg
Member

mkscrg commented Mar 24, 2016

  • Electron version: 0.37.2, 0.34.3
  • Operating system: OSX 10.11.4

Repro Gist: https://gist.github.com/mkscrg/a6f85dba729be431748b (BYO signing cert)

Electron apps signed on OSX 10.11.4 fail codesign --verify on 10.11.3 and lower. We hit this in our production builds, then reproduced it with a minimal Electron app (see Gist) and self-signed cert.

codesign --verify on <= 10.11.3 returns errors similar to this:

.../Codesign Test.app/: invalid signature (code or signature have been modified)
In subcomponent: .../Codesign Test.app/Contents/Frameworks/Codesign Test Helper EH.app

Things we tried/learned along the way:

  • "deep code signing", where each internal framework / helper is signed before the top-level .app (as in the MAS Submission Guide): no difference from repro Gist
  • signing via electron-osx-sign@0.3.0: no difference from repro Gist
  • signing on <= 10.11.3 still works, verifies correctly on 10.11.4
  • a minimal XCode project, built and signed on 10.11.4, verifies correctly on 10.11.3 and lower

Workaround: none, except to sign on a machine running <= 10.11.3.

@kevinsawicki

This comment has been minimized.

Show comment
Hide comment
@kevinsawicki

kevinsawicki Mar 24, 2016

Contributor

@joshaber have you heard anything about signing problems on the latest el cap update?

Contributor

kevinsawicki commented Mar 24, 2016

@joshaber have you heard anything about signing problems on the latest el cap update?

@joshaber

This comment has been minimized.

Show comment
Hide comment
@joshaber

joshaber Mar 24, 2016

Contributor

I haven't, though it's not unheard of for Apple to change how code signing works without publicizing it.

Contributor

joshaber commented Mar 24, 2016

I haven't, though it's not unheard of for Apple to change how code signing works without publicizing it.

@bengotow

This comment has been minimized.

Show comment
Hide comment
@bengotow

bengotow Mar 25, 2016

Contributor

Yeah... unfortunately they changed some things in 10.10 as well without really publicizing it.

Can you try analyzing the codesigned app with these commands? They give more detail than codesign -verify and helped us track down our last codesigning issue (We had a bad symlink in the app, which became a failure condition for codesigning at some point this winter... Found the solution here: http://furbo.org/2015/07/23/code-signing-in-el-capitan/)

codesign --verbose=4 --deep --strict Nylas.app
(strict option is new in El Capitan)

$ spctl -a -v --raw Nylas.app
Nylas.app: rejected
<?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>assessment:authority</key>
    <dict>
        <key>assessment:authority:source</key>
        <string>obsolete resource envelope</string>
        <key>assessment:authority:weak</key>
        <true/>
    </dict>
    <key>assessment:cserror</key>
    <integer>-67003</integer>
    <key>assessment:remote</key>
    <true/>
    <key>assessment:verdict</key>
    <false/>
</dict>
</plist>


Contributor

bengotow commented Mar 25, 2016

Yeah... unfortunately they changed some things in 10.10 as well without really publicizing it.

Can you try analyzing the codesigned app with these commands? They give more detail than codesign -verify and helped us track down our last codesigning issue (We had a bad symlink in the app, which became a failure condition for codesigning at some point this winter... Found the solution here: http://furbo.org/2015/07/23/code-signing-in-el-capitan/)

codesign --verbose=4 --deep --strict Nylas.app
(strict option is new in El Capitan)

$ spctl -a -v --raw Nylas.app
Nylas.app: rejected
<?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>assessment:authority</key>
    <dict>
        <key>assessment:authority:source</key>
        <string>obsolete resource envelope</string>
        <key>assessment:authority:weak</key>
        <true/>
    </dict>
    <key>assessment:cserror</key>
    <integer>-67003</integer>
    <key>assessment:remote</key>
    <true/>
    <key>assessment:verdict</key>
    <false/>
</dict>
</plist>


@mkscrg

This comment has been minimized.

Show comment
Hide comment
@mkscrg

mkscrg Mar 25, 2016

Member

@bengotow thanks! I tried that with a real cert (spctl rejects self-signed certs AFAIK):

  • Signed with --strict on 10.11.4.

    $ codesign --verbose=4 --deep --strict --sign '...' 'Codesign Test-darwin-x64/Codesign Test.app'
    Codesign Test-darwin-x64/Codesign Test.app: signed app bundle with Mach-O thin (x86_64) [com.electron.codesign_test]
    
  • Checked via spctl on 10.11.4 (same machine):

    $ spctl -v -a --raw Codesign\ Test-darwin-x64/Codesign\ Test.app
    Codesign Test-darwin-x64/Codesign Test.app: accepted
    <?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>assessment:authority</key>
        <dict>
                <key>assessment:authority:row</key>
                <integer>6</integer>
                <key>assessment:authority:source</key>
                <string>Developer ID</string>
        </dict>
        <key>assessment:remote</key>
        <true/>
        <key>assessment:verdict</key>
        <true/>
    </dict>
    </plist>
    
  • Zipped and moved to a machine running 10.11.3, checked via spctl there:

    $ spctl -a -v --raw Codesign\ Test.app
    Codesign Test.app: invalid signature (code or signature have been modified)
    
Member

mkscrg commented Mar 25, 2016

@bengotow thanks! I tried that with a real cert (spctl rejects self-signed certs AFAIK):

  • Signed with --strict on 10.11.4.

    $ codesign --verbose=4 --deep --strict --sign '...' 'Codesign Test-darwin-x64/Codesign Test.app'
    Codesign Test-darwin-x64/Codesign Test.app: signed app bundle with Mach-O thin (x86_64) [com.electron.codesign_test]
    
  • Checked via spctl on 10.11.4 (same machine):

    $ spctl -v -a --raw Codesign\ Test-darwin-x64/Codesign\ Test.app
    Codesign Test-darwin-x64/Codesign Test.app: accepted
    <?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>assessment:authority</key>
        <dict>
                <key>assessment:authority:row</key>
                <integer>6</integer>
                <key>assessment:authority:source</key>
                <string>Developer ID</string>
        </dict>
        <key>assessment:remote</key>
        <true/>
        <key>assessment:verdict</key>
        <true/>
    </dict>
    </plist>
    
  • Zipped and moved to a machine running 10.11.3, checked via spctl there:

    $ spctl -a -v --raw Codesign\ Test.app
    Codesign Test.app: invalid signature (code or signature have been modified)
    

@Rokt33r Rokt33r referenced this issue in BoostIO/Boostnote Mar 28, 2016

Closed

Update problem on OS X(to v0.5.7) #7

@javan

This comment has been minimized.

Show comment
Hide comment
@javan

javan Mar 29, 2016

Contributor

I ran into the same issue code signing an Electron 0.37.3 app on OS X 10.11.4 using electron-packager 5.2.1 and resolved it by updating to 6.0.0. I didn't investigate what changed in 6.0.0, but figured I'd share in case it's helpful to others.

Like others, I saw this error on OS X 10.11.3:

$ codesign -vvvv Basecamp\ 3.app
Basecamp 3.app: invalid signature (code or signature have been modified)
In subcomponent: /Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper EH.app

Here's the same app on 10.11.3 signed using electron-packager 6.0.0:

$ codesign -vvvv Basecamp\ 3.app
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper EH.app
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper EH.app
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper NP.app
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper NP.app
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper.app
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper.app
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/.
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/.
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Mantle.framework/Versions/Current/.
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Mantle.framework/Versions/Current/.
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/Current/.
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/Current/.
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Squirrel.framework/Versions/Current/.
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Squirrel.framework/Versions/Current/.
Basecamp 3.app: valid on disk
Basecamp 3.app: satisfies its Designated Requirement
Contributor

javan commented Mar 29, 2016

I ran into the same issue code signing an Electron 0.37.3 app on OS X 10.11.4 using electron-packager 5.2.1 and resolved it by updating to 6.0.0. I didn't investigate what changed in 6.0.0, but figured I'd share in case it's helpful to others.

Like others, I saw this error on OS X 10.11.3:

$ codesign -vvvv Basecamp\ 3.app
Basecamp 3.app: invalid signature (code or signature have been modified)
In subcomponent: /Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper EH.app

Here's the same app on 10.11.3 signed using electron-packager 6.0.0:

$ codesign -vvvv Basecamp\ 3.app
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper EH.app
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper EH.app
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper NP.app
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper NP.app
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper.app
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Basecamp 3 Helper.app
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/.
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/.
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Mantle.framework/Versions/Current/.
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Mantle.framework/Versions/Current/.
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/Current/.
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/Current/.
--prepared:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Squirrel.framework/Versions/Current/.
--validated:/Users/chef/Downloads/Basecamp 3.app/Contents/Frameworks/Squirrel.framework/Versions/Current/.
Basecamp 3.app: valid on disk
Basecamp 3.app: satisfies its Designated Requirement
@mkscrg

This comment has been minimized.

Show comment
Hide comment
@mkscrg

mkscrg Mar 30, 2016

Member

@javan confirmed! electron-packager@6.0.0 solved our problem.

FWIW, we're not using electron-packager to sign, just to package. We're still signing by running codesign explicitly. It's not obvious to me what change in electron-packager solved this issue.

Member

mkscrg commented Mar 30, 2016

@javan confirmed! electron-packager@6.0.0 solved our problem.

FWIW, we're not using electron-packager to sign, just to package. We're still signing by running codesign explicitly. It's not obvious to me what change in electron-packager solved this issue.

@javan

This comment has been minimized.

Show comment
Hide comment
@javan

javan Mar 30, 2016

Contributor

I'm not sure if this is an Electron, OS X 10.11.4, or code signing issue, but it's particularly troubling. In my case, I released a signed app that appeared to work perfectly, and almost immediately people on earlier OS X versions reported autoUpdater and install errors. This caused OS X's Gatekeeper to kick in, preventing launching the app even after downloading a newer, correctly signed version. See http://www.mackungfu.org/dealing-with-damaged-and-can-t-be-opened-error-messages for a solution if you encounter this.

No disrespect to the Electron maintainers intended. I'll continue to investigate and report back if I discover the source of the problem.

Contributor

javan commented Mar 30, 2016

I'm not sure if this is an Electron, OS X 10.11.4, or code signing issue, but it's particularly troubling. In my case, I released a signed app that appeared to work perfectly, and almost immediately people on earlier OS X versions reported autoUpdater and install errors. This caused OS X's Gatekeeper to kick in, preventing launching the app even after downloading a newer, correctly signed version. See http://www.mackungfu.org/dealing-with-damaged-and-can-t-be-opened-error-messages for a solution if you encounter this.

No disrespect to the Electron maintainers intended. I'll continue to investigate and report back if I discover the source of the problem.

@hongrich

This comment has been minimized.

Show comment
Hide comment
@hongrich

hongrich Mar 30, 2016

Contributor

It seems that CFBundleExecutable in Info.plist actually needs to match the name of the executable now. If you rename the helper executable from Electron Helper EH to MyApp Helper EH but didn't update CFBundleExecutable in the helper's Info.plist, then this issue happens. electron-packager updates CFBundleExecutable for all the helpers and renames the executables as well to the same thing.

Making them match worked for me. Can someone else try this and see if it works for them too?

Contributor

hongrich commented Mar 30, 2016

It seems that CFBundleExecutable in Info.plist actually needs to match the name of the executable now. If you rename the helper executable from Electron Helper EH to MyApp Helper EH but didn't update CFBundleExecutable in the helper's Info.plist, then this issue happens. electron-packager updates CFBundleExecutable for all the helpers and renames the executables as well to the same thing.

Making them match worked for me. Can someone else try this and see if it works for them too?

@mkscrg

This comment has been minimized.

Show comment
Hide comment
@mkscrg

mkscrg Mar 30, 2016

Member

@hongrich yep, that seems to be it. Confirmed I can do this on 10.11.4:

  • package with electron-packager@5.2.1

  • fix CFBundleExecutable in the the helper apps:

    /usr/libexec/PlistBuddy \
      -c "set :CFBundleExecutable \"$app_name Helper EH\"" \
      "$dist_dir/$app_name.app/Contents/Frameworks/$app_name Helper EH.app/Contents/Info.plist"
    /usr/libexec/PlistBuddy \
      -c "set :CFBundleExecutable \"$app_name Helper NP\"" \
      "$dist_dir/$app_name.app/Contents/Frameworks/$app_name Helper NP.app/Contents/Info.plist"
    
  • codesign the top-level bundle with codesign --force.

Then I can take the signed app to 10.11.3 and pass codesign --verify.

Still unclear to me how 10.11.4 fits into this picture!

Member

mkscrg commented Mar 30, 2016

@hongrich yep, that seems to be it. Confirmed I can do this on 10.11.4:

  • package with electron-packager@5.2.1

  • fix CFBundleExecutable in the the helper apps:

    /usr/libexec/PlistBuddy \
      -c "set :CFBundleExecutable \"$app_name Helper EH\"" \
      "$dist_dir/$app_name.app/Contents/Frameworks/$app_name Helper EH.app/Contents/Info.plist"
    /usr/libexec/PlistBuddy \
      -c "set :CFBundleExecutable \"$app_name Helper NP\"" \
      "$dist_dir/$app_name.app/Contents/Frameworks/$app_name Helper NP.app/Contents/Info.plist"
    
  • codesign the top-level bundle with codesign --force.

Then I can take the signed app to 10.11.3 and pass codesign --verify.

Still unclear to me how 10.11.4 fits into this picture!

@kevinsawicki

This comment has been minimized.

Show comment
Hide comment
@kevinsawicki

kevinsawicki Mar 30, 2016

Contributor

Going to close this out since it seems to be an Info.plist behavior change between 10.11.3 and 10.11.4 that can't be addressed by a change to Electron but instead via an electron-packager upgrade to at least 6.0.0.

Thanks so much to everyone who helped out here 👍 👍 👍

Contributor

kevinsawicki commented Mar 30, 2016

Going to close this out since it seems to be an Info.plist behavior change between 10.11.3 and 10.11.4 that can't be addressed by a change to Electron but instead via an electron-packager upgrade to at least 6.0.0.

Thanks so much to everyone who helped out here 👍 👍 👍

@javan

This comment has been minimized.

Show comment
Hide comment
@javan

javan Mar 30, 2016

Contributor

❤️

Contributor

javan commented Mar 30, 2016

❤️

@mitsuhiko mitsuhiko referenced this issue in lektor/lektor Apr 11, 2016

Closed

Problem installing Lektor v2.0 dmg #195

@mitsuhiko

This comment has been minimized.

Show comment
Hide comment
@mitsuhiko

mitsuhiko Apr 12, 2016

If someone else encounters this in the future: another reason this can happen is if you have another executable in the MacOS folder that is not referenced by the Info.plist file.

If someone else encounters this in the future: another reason this can happen is if you have another executable in the MacOS folder that is not referenced by the Info.plist file.

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Apr 12, 2016

Contributor

Thanks for tracking this down @hongrich

Contributor

paulcbetts commented Apr 12, 2016

Thanks for tracking this down @hongrich

@EragonJ EragonJ referenced this issue in EragonJ/Kaku Apr 14, 2016

Closed

Release 1.7.0 #389

1 of 1 task complete

@hollyschinsky hollyschinsky referenced this issue in phonegap/phonegap-app-desktop May 26, 2016

Closed

Updating Fails #633

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment