841929 - Unable to launch apps installed on OS X 10.8

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Web Apps, defect, P3)

Description

[Maria Sandberg [:mushi]]

Attachment: .tiff - can't launch app

Seems like MacOS (Mountain Lion 10.8.2) "protects" users from launching apps not from the App store. 

This dialogue is shown both if I try and launch the app from the Marketplace site, or from the desktop itself. Since it doesn't give any hint on how to resolve the issue I'm worried users will think the app is broken and give up. Screenshot attached.

Comment 1

[Maria Sandberg [:mushi]]

Attachment: .png - can't launch app

aaaand .tiff doesn't work in bugzilla. attaching .png

Comment 2

[Christopher Van Wiemeersch [:cvan]]

This seems like a platform/Mac OS X security issue. I don't know?

Comment 3

[Jason Smith [:jsmith]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #2)
> This seems like a platform/Mac OS X security issue. I don't know?

Oh hell. This problem. Dan and I tried to reproduce this a long time ago, but couldn't reproduce it. Apparently it's possible.

Bad news is with the decreased focus on desktop, I doubt this will get fixed anytime soon. But I'm ccing Dan in case he wants to take a look into this.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Marco: can you look at this and figure out if it's a hard limitation of the new version of the OS?

Comment 5

[Marco Castelluccio [:marco]]

I can't reproduce.

Comment 6

[Marco Castelluccio [:marco]]

http://support.apple.com/kb/HT5290

Looks like "Gatekeeper" allows, by defauly, only signed apps or apps installed from the Mac App Store.
If apps are not downloaded from internet (and this should be our case, because for Mac the app is the webapp runtime) they're allowed to run by default.

Comment 8

[Marco Castelluccio [:marco]]

We probably need to sign the webrt files like we do for Firefox files (the relevant code is here: https://mxr.mozilla.org/mozilla-central/source/browser/app/macbuild/Contents/_CodeSignature/)

Comment 9

[[e-mail] (:bhearsum)]

I don't know enough about installable apps to be of use here, I think. If these are something that Mozilla needs to sign, I can help the appropriate folks on the Apps side get a Developer ID to sign with. I can also help get someone up to speed on the tooling and how we automate signing for Firefox.

If these are something that application developers should be signing themselves, I'm probably not any help.

Comment 10

[Benjamin Smedberg]

Marco, that code is used to sign Firefox before it is shipped, using a private key held by releng. It won't help at all with the case of us dynamically generating bundles on the client.

Comment 11

[Marco Castelluccio [:marco]]

Do we need to sign all the files that are in an app bundle? Or do we just need to sign the executable?

Comment 12

[[e-mail] (:bhearsum)]

(In reply to Marco Castelluccio [:marco] from comment #11)
> Do we need to sign all the files that are in an app bundle? Or do we just
> need to sign the executable?

Mac applications aren't signed on a per-file basis. Checksums of the files are put into CodeResources and then some magic happens and adjusts the header of binary that gets launched (eg, Contents/MacOS/firefox-bin). Before signing you can put some excludes into the CodeResources file.

So, the .app as a whole is signed, not the individual files inside. This requires a Developer ID and a Mac machine with "signcode" on it. (I believe that it comes with Xcode.) Apple's guide is actually quite good:
https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html

Comment 13

[Florian Bender]

Chrome Web Apps work without Gatekeeper interfering, and I'm pretty sure they don't sign them on the user's machine. ;)

So there needs to be a way around this issue. Don't know if this is in the Chromium source, though. Anybody know anyone that knows how Google is doing that?

Comment 14

[Marco Castelluccio [:marco]]

I've talked with Ben on IRC, maybe we can sign just the executable and omit the configuration files. Signing the executable should be simple because it's shipped with Firefox.

Comment 15

[[e-mail] (:bhearsum)]

(In reply to Marco Castelluccio [:marco] from comment #14)
> I've talked with Ben on IRC, maybe we can sign just the executable and omit
> the configuration files. Signing the executable should be simple because
> it's shipped with Firefox.

To expand on this, Marco told me that that webapprt.app that ships with Firefox needs to be signed. We already do signing of the overall Firefox.app at packaging time. Someone will need to write some build system code that makes use of MOZ_SIGN_CMD to sign webapprt .app at this time. Basically, you need to do something like:
https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/packager.mk#565 (definition of the full signing command - you can probably skip the includes/excludes though)
https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/packager.mk#577 (execution of the signing command)

When run on our infrastructure, $(MOZ_SIGN_CMD) will be set to talk with our signing servers and eventually return a signed package.

Comment 16

[Florian Bender]

I don't know if this is Nightly/Aurora-specific, but the current builds seem to have a signed webrt-stub. At least Gatekeeper doesn't complain, and I can install and launch Web Apps like from the App Store! Was there a change in the infrastructure lately?

Comment 17

[[e-mail] (:bhearsum)]

(In reply to Florian Bender from comment #16)
> I don't know if this is Nightly/Aurora-specific, but the current builds seem
> to have a signed webrt-stub. At least Gatekeeper doesn't complain, and I can
> install and launch Web Apps like from the App Store! Was there a change in
> the infrastructure lately?

Nothing that I'm aware of...

Would you mind running 'codesign -vvv' on the webrt-stub package? That should give signature information.

Comment 18

[Florian Bender]

Both Nightly and Aurora say "webapprt-stub: code object is not signed at all". Odd. I'll wait for 28 Beta and test again.

Comment 19

[[e-mail] (:bhearsum)]

(In reply to Florian Bender from comment #18)
> Both Nightly and Aurora say "webapprt-stub: code object is not signed at
> all". Odd. I'll wait for 28 Beta and test again.

Is webapprt-stub a .app, or something else? What happens if your run codesign -vvv on one from Beta or Nightly?

Comment 20

[Marco Castelluccio [:marco]]

(In reply to Ben Hearsum [:bhearsum] from comment #19)
> (In reply to Florian Bender from comment #18)
> > Both Nightly and Aurora say "webapprt-stub: code object is not signed at
> > all". Odd. I'll wait for 28 Beta and test again.
> 
> Is webapprt-stub a .app, or something else? What happens if your run
> codesign -vvv on one from Beta or Nightly?

webapprt-stub is an executable file. I can confirm it isn't signed.
I can also confirm that apps installed with Nightly can be executed, while apps installed with a release version can't (this is why I wasn't able to reproduce the problem before, I've always tried with a Nightly build).

Comment 21

[Florian Bender]

I just tried it again with 34 Beta (GateKeeper blocks execution) and 35 DevEdition (works, though at the first attempt the App did not show up in the App directory). The overall situation has changed now, too, due to the new signature requirements for Yosemite. Does this help in finally finding a solution for this issue?

Comment 22

[Joshua Smith]

This is not a solution, but we address this issue by telling users to open the app with a right-click. If you do that, you get a dialog you can actually OK, and after that you can run the apps.

Here's a code snippet from our server page:

  req.onsuccess = function() {
    alert(navigator.userAgent.match(/Mac/) ?
          'Find [{{ app.title|safe }}] in your Applications folder, right-click, and choose "Open"' :
          'A shortcut to [{{ app.title|safe }}] can be found on your Desktop');

Comment 23

[Myk Melez [:myk] [@mykmelez]]

Per bug 1238079, we're going to disable the desktop web runtime and remove it
from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.