Re: Heads Up: Apple Notarized Nightly Builds

u have any questions. Thanks, Haik On Wed, Jun 26, 2019 at 1:27 PM Haik Aftandilian wrote: > Release Engineering will soon be turning on Apple Notarization and > Hardened Runtime[1] for Nightly channel builds. See previous discussion[2] > on dev-platform for more information. > > F

Heads Up: Apple Notarized Nightly Builds

Release Engineering will soon be turning on Apple Notarization and Hardened Runtime[1] for Nightly channel builds. See previous discussion[2] on dev-platform for more information. First, I want to recognize that this required a very significant amount of work from the Release Engineering team to

Re: Apple Notary Service and Debugging Impact

On Thu, Apr 11, 2019 at 7:45 AM Boris Zbarsky wrote: > On 4/11/19 3:07 AM, Haik Aftandilian wrote: > > With notarization, Nightly channel builds will not be debuggable unless > the > > system is booted with system integrity protection (SIP)[1] disabled. > > Do you k

Re: Apple Notary Service and Debugging Impact

> been a handful of times that I had to debug an official build. Having to > disable SIP to debug isn't ideal, but tolerable given how infrequently > this would be necessary. I'd be interested to hear if others have had to > debug official builds more frequently. > > -spohl > > On

Apple Notary Service and Debugging Impact

Please take a look if you debug Firefox on macOS. Apple's notary service[1] is a new way to sign macOS applications that has some security benefits[2] and provides a slight user experience improvement[3] when users download the application and run it for the first time. Specifically, the dialog

New macOS mach run option: --macos-open

With the fix for bug 1494326[1] (on autoland), when run on macOS, "mach run" has a new option "--macos-open" to launch the browser using the open(1) command. Note --macos-open and --debug are mutually exclusive and mach will exit with an error if both options are used. Per the open(1) man page,

Re: mozilla-central Fails to Build on Mac With Latest Xcode (10.0)

This has been resolved. The fix for bug 1492210 is now in mozilla-central, thanks to Miko. Haik On Tue, Sep 18, 2018 at 11:30 AM Haik Aftandilian wrote: > If you don't build on macOS, read no further. > > With the latest XCode (10.0) just released, mozilla-central fails to build >

mozilla-central Fails to Build on Mac With Latest Xcode (10.0)

If you don't build on macOS, read no further. With the latest XCode (10.0) just released, mozilla-central fails to build due to bug 1492210 "nsCocoaUtils.mm compile error on macOS 10.13 with 10.14 SDK" [1]. I recommend avoiding installing the new XCode until we have this fixed. If you've

Re: Removing tinderbox-builds from archive.mozilla.org

On Sun, May 13, 2018 at 8:00 AM, Jean-Yves Avenard wrote: > Hi > On 12/05/2018 04:47, Boris Zbarsky wrote: > >> Just to be clear, when doing a bisect, one _can_ just deal with local >> builds. But the point is that then it takes tens of minutes per build as >> you point

Re: Intent to ship: macOS Flash NPAPI Sandbox

On Tue, Mar 20, 2018 at 10:54 AM, Haik Aftandilian <haftandil...@mozilla.com > wrote: > We intend to ship a process-level sandbox for the NPAPI Flash plugin on > macOS in 61. This will provide a degree of process isolation at the expense > of some lesser-used Flash functional

Intent to ship: macOS Flash NPAPI Sandbox

We intend to ship a process-level sandbox for the NPAPI Flash plugin on macOS in 61. This will provide a degree of process isolation at the expense of some lesser-used Flash functionality[1]. You can enable the sandbox now on Nightly, globally for all sites, by setting

Re: Commit messages in Phabricator

On Mon, Feb 12, 2018 at 6:30 AM, Eric Rescorla wrote: > On Mon, Feb 12, 2018 at 6:09 AM, Boris Zbarsky wrote: > Instead, maybe we can arrange for Phab/Lando to put the bug #in the short > message, potentially also with r= > ​I agree. Having the bug ID on the

Re: Enabling filesystem read-restrictions for content process sandbox

On Fri, Jul 21, 2017 at 7:48 AM, Andrea Marchesini wrote: > There are some APIs able to read files in the content process using > nsFileInputStream: FileReader is one of them. > The file is opened on the parent process (because of a FilePicker, or > Entries API), the

Re: Ambient Light Sensor API

Which, from my perspective, is justification to disable reading the sensor until it can be implemented in a way that prevents the cross-origin stealing attack. Users shouldn't have to worry about this. Haik On Wed, Apr 26, 2017 at 8:28 AM, Ehsan Akhgari wrote: > On

Re: What are your use cases for the Touch Bar on the new MacBook Pro?

What about using it to help detect phishing sites. For example, when filling out a user/password form, if the touch bar displayed the domain name (not the full URL) we're submitting to (for example mybank.com), that might help prevent some phishing attacks. The user just has to glance down at the

Heads Up: Mac CFMessagePort/CFPasteboardSetup Error Messages

Since the integration of bug 1299329 ​[1] ​ ​in Nightly, these error messages are printed to the terminal and system.log so you'll see them when running Firefox from the command line on Mac. ​They are not known to cause any browser issues so you can ignore them. These are due to sandbox

OS X Nightly Content Sandbox Changes

The fix for bug 1272772 [1] makes some minor changes to the OS X content sandbox which is only enabled on Nightly. More changes will come as we whittle down and simplify the sandbox rules. If you think you are hitting a regression due to sandboxing on OS X, it's a good idea to check the OS X

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On Fri, Apr 15, 2016 at 7:37 PM, Chris Peterson wrote: > On 4/15/16 7:47 AM, Tantek Çelik wrote: > >> What steps can we take in this direction WITHOUT breaking web compat? >> > > Would this feature actually break web compatibility? Or just needlessly > annoy users? > > In

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On Thu, Apr 14, 2016 at 1:54 AM, Chris Peterson wrote: > Summary: Treat cookies set over non-secure HTTP as session cookies > > Exactly one year ago today (!), Henri Sivonen proposed [1] treating > cookies without the `secure` flag as session cookies. > > PROS: > > *

Re: To bump mochitest's timeout from 45 seconds to 90 seconds

On Tue, Feb 9, 2016 at 2:47 AM, Marco Bonardo wrote: > Based on that, bumping the timeout may have 2 downsides, long term: > - slower tests for everyone > - sooner or later 90 seconds won't be enough again. Are we going to bump to > 180 then? > Essentially restating