Re: Upcoming changes to Mac package layout, signing
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 rstr...@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. Thanks go out to everyone involved in making this happen on such short notice! Cheers, Robert -Original Message- From: Robert Strong [mailto:rstr...@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- 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Upcoming changes to Mac package layout, signing
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:rstr...@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- 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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-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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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? 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
- Original Message - From: Philipp Kewisch mozi...@kewis.ch To: dev-platform@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
On 8/27/14, 8:16 PM, Boris Zbarsky wrote: 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? Er, nevermind, I see this was addressed up-thread. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Upcoming changes to Mac package layout, signing
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=mozilla@lists.mozilla.org] On Behalf Of Robert Strong Sent: Wednesday, August 27, 2014 5:16 PM To: dev-platform@lists.mozilla.org Subject: Re: Upcoming changes to Mac package layout, signing - Original Message - From: Philipp Kewisch mozi...@kewis.ch To: dev-platform@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
On Wed, Aug 27, 2014 at 5:16 PM, Robert Strong rstr...@mozilla.com wrote: - Original Message - From: Philipp Kewisch mozi...@kewis.ch To: dev-platform@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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
On 8/14/14, 5:02 AM, Neil wrote: 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. Anything? Where does omni.ja go? 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
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 changesRob, 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Upcoming changes to Mac package layout, signing
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=1046906hide_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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 bhear...@mozilla.com 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. 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=1046906hide_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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
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). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Upcoming changes to Mac package layout, signing
Yes, this is very much on our radar. Cheers, Robert -Original Message- From: dev-platform [mailto:dev-platform-bounces+rstrong=mozilla@lists.mozilla.org] On Behalf Of Ehsan Akhgari Sent: Tuesday, August 12, 2014 5:33 PM To: Ben Hearsum Cc: dev-platform@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 bhear...@mozilla.com 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. 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=1046906hide_resolv ed=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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
