Upcoming changes to Mac package layout, signing

[Ben Hearsum]

Hi all,

Apple recently announced changes to how OS X applications must be packaged and signed (https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205) in order for them to function correctly on OS X 10.9.5 and 10.10. The tl;dr version of this is "only mach-O binaries may live in .app/Contents/MacOS, and signing must be done on 10.9 or later". Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. We do not have a release date for either of these OS X versions yet.

Changes required:
* Move all non-mach-O files out of .app/Contents/MacOS. Most of these will move to .app/Contents/Resources, but files that could legitimately change at runtime (eg: everything in defaults/) will move to .app/MozResources (which can be modified without breaking the signature): https://bugzilla.mozilla.org/showdependencytree.cgi?id=1046906&hide_resolved=1. This work is in progress, but no patches are ready yet.
* Add new features to the client side update code to allow partner repacks to continue to work. (https://bugzilla.mozilla.org/show_bug.cgi?id=1048921)
* Create and use 10.9 signing servers for these new-style apps. We still need to use our existing 10.6 signing servers for any builds without these changes. (https://bugzilla.mozilla.org/show_bug.cgi?id=1046749 and https://bugzilla.mozilla.org/show_bug.cgi?id=1049595)
* Update signing server code to support new v2 signatures.

Timeline:
We are intending to ship the required changes with Gecko 34, which ships on November 25th, 2014. The changes required are very invasive, and we don't feel that they can be safely backported to any earlier version quickly enough without major risk of regressions. We are still looking at whether or not we'll backport to ESR 31. To this end, we've asked that Apple whitelist Firefox and Thunderbird versions that will not have the necessary changes in them. We're still working with them to confirm whether or not this can happen.

This has been cross posted a few places - please send all follow-ups to the mozilla.dev.platform newsgroup.

- Ben

[Ehsan Akhgari]

One thing to test heavily would be background updates which rely somewhat
on the structure of these files abd directories...

Cheers,
Ehsan

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Cameron McCormack]

Ben Hearsum wrote:
> Apple recently announced changes to how OS X applications must be packaged and signed

Does this also apply if you run .app/Contents/MacOS/firefox binary
manually rather than opening the .app?

If developers do update their OS to 10.9.5 when it's released, is there
a way to override this check? Otherwise it's going to make it difficult
to run older builds (e.g. manually testing old builds for regressions,
or using mozregression that does Nightly build bisection).

[Robert Strong]

Yes, this is very much on our radar.

Cheers,
Robert

-----Original Message-----
From: dev-platform
[mailto:dev-platform-bounces+rstrong=mozil...@lists.mozilla.org] On
Behalf Of Ehsan Akhgari
Sent: Tuesday, August 12, 2014 5:33 PM
To: Ben Hearsum
Cc: dev-pl...@lists.mozilla.org
Subject: Re: Upcoming changes to Mac package layout, signing

One thing to test heavily would be background updates which rely somewhat
on the structure of these files abd directories...

Cheers,
Ehsan
On Aug 12, 2014 1:05 PM, "Ben Hearsum" <bhea...@mozilla.com> wrote:

[Stephen Pohl]

On 8/12/14, 8:46 PM, Cameron McCormack wrote:

> Ben Hearsum wrote:
>> Apple recently announced changes to how OS X applications must be
>> packaged and signed
>

> Does this also apply if you run .app/Contents/MacOS/firefox binary
> manually rather than opening the .app?
>

As best as I can tell, no. You should be able to run the firefox binary
manually without a warning dialog.

> If developers do update their OS to 10.9.5 when it's released, is
> there a way to override this check? Otherwise it's going to make it
> difficult to run older builds (e.g. manually testing old builds for
> regressions, or using mozregression that does Nightly build bisection).
>

The most bullet-proof way to override this behavior is to change the
Gatekeeper setting. This can be done in System Preferences > Security &
Privacy by setting "Allow apps downloaded from:" to "Anywhere". This
obviously comes with the downside that the Gatekeeper will be disabled
for all apps.

If apps should be allowed individually, simply right-click the bundle
and select "Open". The warning dialog should no longer appear on
subsequent launch attempts.

[Philipp Kewisch]

On 8/12/14 7:05 PM, Ben Hearsum wrote:
> Hi all,
>
> Apple recently announced changes to how OS X applications must be packaged and signed (https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205) in order for them to function correctly on OS X 10.9.5 and 10.10. The tl;dr version of this is "only mach-O binaries may live in .app/Contents/MacOS, and signing must be done on 10.9 or later". Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. We do not have a release date for either of these OS X versions yet.
>

Does this also affect binary extensions in any way? I'd imagine that
globally installed extensions would break signing if placed incorrectly.

If this is the case, is it enough to sign the extension with a
(non-self-signed) certificate, or does the app code signing need to be
modified too? I assume old extensions versions will then need to be
re-signed when the certificate expires, it would be nice to have a way
to do this in AMO without changing the version number each time.

Philipp

[Benjamin Smedberg]

On 8/13/2014 3:34 AM, Philipp Kewisch wrote:
>
> Does this also affect binary extensions in any way? I'd imagine that
> globally installed extensions would break signing if placed incorrectly.

You cannot place anything in the Firefox bundle. Any extensions, binary
or not, would need to be elsewhere. I don't know that we have a
supported global install location on Mac.

--BDS

[Ben Hearsum]

On 14-08-12 08:46 PM, Cameron McCormack wrote:
> Ben Hearsum wrote:
>> Apple recently announced changes to how OS X applications must be
>> packaged and signed
>
> Does this also apply if you run .app/Contents/MacOS/firefox binary
> manually rather than opening the .app?

I'm not sure about that. I also seem some discussion that running like
that may not work after these changes....Rob, do you remember the
details there?

> If developers do update their OS to 10.9.5 when it's released, is there
> a way to override this check? Otherwise it's going to make it difficult
> to run older builds (e.g. manually testing old builds for regressions,
> or using mozregression that does Nightly build bisection).

You can disable all of these checks in the System Preferences, so this
shouldn't be an issue for regression hunting, QA, etc. We're concerned
with the out-of-box experience for average users.

- Ben

[Neil]

Anything? Where does omni.ja go?

--
Warning: May contain traces of nuts.

[Stephen Pohl]

omni.ja goes in Contents/Resources[1]. Anything added before signing is
okay. After signing, nothing can be added/modified inside of .app/Contents.

We are exploring a workaround where we place/modify files in
.app/MozResources after signing[2]. We believe this will work, but we
will need to confirm with a working implementation.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1047584
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1047728

[Philipp Kewisch]

When you say not supported, does this mean you have no motivation or
plans to allow extensions formerly dropped in Contents/MacOS/extensions/
to be placed in a different location that doesn't require resigning?

I suspect this means enterprise administrators will need to resign if
they want to install Firefox on many machines and provide preinstalled
extensions?

On a related matter, has Stephan's suspicion been confirmed that running
the binary manually will not trigger gatekeeper and allow developers to
run the app, with all extensions in
obj/dist/Nightly.app/Contents/MacOS/extensions/ (where they end up with
--enable-extensions)

Thanks,
Philipp

[Boris Zbarsky]

On 8/12/14, 1:05 PM, Ben Hearsum wrote:
> Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10.

Will it still be possible to run old nightlies, presumably by changing
something in system settings?

-Boris

[Robert Strong]

----- Original Message -----
> From: "Philipp Kewisch" <moz...@kewis.ch>
> To: dev-pl...@lists.mozilla.org
> Sent: Wednesday, August 27, 2014 4:49:35 PM
> Subject: Re: Upcoming changes to Mac package layout, signing
>

> On 8/13/14 2:59 PM, Benjamin Smedberg wrote:
> >
> > On 8/13/2014 3:34 AM, Philipp Kewisch wrote:
> >>
> >> Does this also affect binary extensions in any way? I'd imagine that
> >> globally installed extensions would break signing if placed incorrectly.
> >
> > You cannot place anything in the Firefox bundle. Any extensions, binary
> > or not, would need to be elsewhere. I don't know that we have a
> > supported global install location on Mac.
> >
> > --BDS
> >
>
> When you say not supported, does this mean you have no motivation or
> plans to allow extensions formerly dropped in Contents/MacOS/extensions/
> to be placed in a different location that doesn't require resigning?

It does not mean that we won't support another location. We are moving as fast as we can to get the minimum requirements finished at this time and it would be helpful if someone tackled the specific issue of supporting another location. First step would be checking if Mac supports a system / global install location for extensions outside of the bundle.

>
> I suspect this means enterprise administrators will need to resign if
> they want to install Firefox on many machines and provide preinstalled
> extensions?

Unless there is a system / global install location available.

>
> On a related matter, has Stephan's suspicion been confirmed that running
> the binary manually will not trigger gatekeeper and allow developers to
> run the app, with all extensions in
> obj/dist/Nightly.app/Contents/MacOS/extensions/ (where they end up with
> --enable-extensions)

We will be investigating that further after we finish up the minimum requirements.

Robert

[Boris Zbarsky]

Er, nevermind, I see this was addressed up-thread.

-Boris

[Robert Strong]

Extension manager docs on install locations shows that Mac has a system
install location
https://developer.mozilla.org/en-US/Add-ons/Installing_extensions

Robert

-----Original Message-----
From: dev-platform
[mailto:dev-platform-bounces+rstrong=mozil...@lists.mozilla.org] On

Behalf Of Robert Strong
Sent: Wednesday, August 27, 2014 5:16 PM
To: dev-pl...@lists.mozilla.org
Subject: Re: Upcoming changes to Mac package layout, signing



----- Original Message -----
> From: "Philipp Kewisch" <moz...@kewis.ch>
> To: dev-pl...@lists.mozilla.org
> Sent: Wednesday, August 27, 2014 4:49:35 PM
> Subject: Re: Upcoming changes to Mac package layout, signing
>

> On 8/13/14 2:59 PM, Benjamin Smedberg wrote:
> >
> > On 8/13/2014 3:34 AM, Philipp Kewisch wrote:
> >>
> >> Does this also affect binary extensions in any way? I'd imagine
> >> that globally installed extensions would break signing if placed
incorrectly.
> >
> > You cannot place anything in the Firefox bundle. Any extensions,
> > binary or not, would need to be elsewhere. I don't know that we have
> > a supported global install location on Mac.
> >
> > --BDS
> >
>
> When you say not supported, does this mean you have no motivation or
> plans to allow extensions formerly dropped in
> Contents/MacOS/extensions/ to be placed in a different location that
doesn't require resigning?

It does not mean that we won't support another location. We are moving as
fast as we can to get the minimum requirements finished at this time and
it would be helpful if someone tackled the specific issue of supporting
another location. First step would be checking if Mac supports a system /
global install location for extensions outside of the bundle.

>

> I suspect this means enterprise administrators will need to resign if
> they want to install Firefox on many machines and provide preinstalled
> extensions?

Unless there is a system / global install location available.

>

> On a related matter, has Stephan's suspicion been confirmed that
> running the binary manually will not trigger gatekeeper and allow
> developers to run the app, with all extensions in
> obj/dist/Nightly.app/Contents/MacOS/extensions/ (where they end up
> with
> --enable-extensions)

We will be investigating that further after we finish up the minimum
requirements.

Robert

[Dave Townsend]

On Wed, Aug 27, 2014 at 5:16 PM, Robert Strong <rst...@mozilla.com> wrote:

>
>
> ----- Original Message -----
> > From: "Philipp Kewisch" <moz...@kewis.ch>
> > To: dev-pl...@lists.mozilla.org
> > Sent: Wednesday, August 27, 2014 4:49:35 PM
> > Subject: Re: Upcoming changes to Mac package layout, signing
> >

> > On 8/13/14 2:59 PM, Benjamin Smedberg wrote:
> > >
> > > On 8/13/2014 3:34 AM, Philipp Kewisch wrote:
> > >>
> > >> Does this also affect binary extensions in any way? I'd imagine that
> > >> globally installed extensions would break signing if placed
> incorrectly.
> > >
> > > You cannot place anything in the Firefox bundle. Any extensions, binary
> > > or not, would need to be elsewhere. I don't know that we have a
> > > supported global install location on Mac.
> > >
> > > --BDS
> > >
> >
> > When you say not supported, does this mean you have no motivation or
> > plans to allow extensions formerly dropped in Contents/MacOS/extensions/
> > to be placed in a different location that doesn't require resigning?

> It does not mean that we won't support another location. We are moving as
> fast as we can to get the minimum requirements finished at this time and it
> would be helpful if someone tackled the specific issue of supporting
> another location. First step would be checking if Mac supports a system /
> global install location for extensions outside of the bundle.
>
>

If my reading of the patches are correct then the extension manager will
start looking in the new location in the app bundle for extensions
(Contents/Resources/browser/extensions) automatically. We'll have to
support this as that is where the default theme is to be found.

> >
> > I suspect this means enterprise administrators will need to resign if
> > they want to install Firefox on many machines and provide preinstalled
> > extensions?

> Unless there is a system / global install location available.
>

As you noted there is a system install location available on OSX.

[Benjamin Smedberg]

On 8/28/14, 1:04 AM, Dave Townsend wrote:
>
> If my reading of the patches are correct then the extension manager will
> start looking in the new location in the app bundle for extensions
> (Contents/Resources/browser/extensions) automatically. We'll have to
> support this as that is where the default theme is to be found.

We should support this as little as possible. If anyone actually *did*
drop extensions into that location, it may break the application
signature for users. And even worse, the signature break might not show
up immediately, but whenever MacOS decides to re-check the signature.

I suggest that to the extent we have to have a default theme there, we
should explicitly limit this location to only the default theme.

--BDS

[Robert Strong]

Quick status update on the progress for Mac v2 signing.

All of the major changes for Mac v2 signing have landed on the Oak branch.
This will allow us to test installing and updating before landing on
mozilla-central.
https://bugzilla.mozilla.org/show_bug.cgi?id=1046906
https://bugzilla.mozilla.org/show_bug.cgi?id=1046306
https://bugzilla.mozilla.org/show_bug.cgi?id=1047584
and the dependent bugs

If no serious issues are found we are hoping to be able to land on
mozilla-central later this week.

There have been no significant deviations from what has been previously
discussed in this thread and the current plan is to still target Firefox
34.

We will be looking into how to get back parity on Mac to the current
capabilities for distributions and administrative configurations after we
finish the current work.

Cheers,
Robert

[Henrik Skupin]

Robert Strong wrote on 09/22/2014 11:07 AM:

Hi Robert,

> All of the major changes for Mac v2 signing have landed on the Oak branch.
> This will allow us to test installing and updating before landing on
> mozilla-central.

[..]

>
> If no serious issues are found we are hoping to be able to land on
> mozilla-central later this week.

Thanks a lot for this update. In case of our Mozmill update tests, those
have been updated yesterday for Nightly to be able to handle the new
signed builds. If all goes well with updates today, I will backport my
patch on bug 1063584 to Aurora today.

There are only two issues left for the mozmill-automation package, which
I hopefully can finish up by today or tomorrow.

https://github.com/mozilla/mozmill-automation/milestones/2.0.8.1

That means we should then be able to run our update tests against builds
of the oak tree, which should give an extra bit of safety.

Cheers,

--
Henrik

[Robert Strong]

The Mac package layout and signing changes merged to mozilla-central on
Tuesday and the new layout will be present in the update on Wednesday.
There are a couple of files still in the bundle after the first update to
the new layout that will make the signature invalid. This shouldn't cause
any problems since the signature is currently only checked on first launch
after installing from the dmg and these files will be removed on the next
update which should make the signature valid. Also, the signature should
be valid when installing from the dmg as well as after each update from
then on.

If you find any bugs that you believe are due to these changes please file
a new bug under toolkit -> application update and we'll take it from
there.

Thanks go out to everyone involved in making this happen on such short
notice!

Cheers,
Robert

> -----Original Message-----
> From: Robert Strong [mailto:rst...@mozilla.com]
> Sent: Monday, September 22, 2014 2:07 AM
> To: dev-platform
> Subject: RE: Upcoming changes to Mac package layout, signing
>
> Quick status update on the progress for Mac v2 signing.
>

> All of the major changes for Mac v2 signing have landed on the Oak
branch.
> This will allow us to test installing and updating before landing on
mozilla-
> central.

> https://bugzilla.mozilla.org/show_bug.cgi?id=1046906
> https://bugzilla.mozilla.org/show_bug.cgi?id=1046306
> https://bugzilla.mozilla.org/show_bug.cgi?id=1047584
> and the dependent bugs
>

> If no serious issues are found we are hoping to be able to land on
mozilla-

[Henrik Skupin]

Robert Strong wrote on 10/01/2014 06:22 AM:

Hi Robert,

> If you find any bugs that you believe are due to these changes please file
> a new bug under toolkit -> application update and we'll take it from
> there.

Thanks for the update. Beside the crasher bug we found, and which has
been fixed we do not see any other regression via our Mozmill tests due
to this change.

--
Henrik

[Syd Polk]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1075985 to cover the fact that steeplechase does not work with the new layout. This is more of an FYI.

Syd Polk
sp...@mozilla.com
+1-512-905-9904
irc: sydpolk

On Sep 30, 2014, at 23:22, Robert Strong <rst...@mozilla.com> wrote:

> The Mac package layout and signing changes merged to mozilla-central on
> Tuesday and the new layout will be present in the update on Wednesday.
> There are a couple of files still in the bundle after the first update to
> the new layout that will make the signature invalid. This shouldn't cause
> any problems since the signature is currently only checked on first launch
> after installing from the dmg and these files will be removed on the next
> update which should make the signature valid. Also, the signature should
> be valid when installing from the dmg as well as after each update from
> then on.
>

> If you find any bugs that you believe are due to these changes please file
> a new bug under toolkit -> application update and we'll take it from
> there.
>