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

[Haik Aftandilian]

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 bar to confirm they're submitting to
mybank.com.

This only works if we don't allow web pages to control what is displayed on
the touch bar.

On Tue, Jan 3, 2017 at 9:17 AM, Stephen A Pohl  wrote:

> We are gathering ideas for possible use cases of the Touch Bar on the
> new MacBookPro and would like to hear from you! What would improve your
> workflow? What would help our users?
>
> We will develop[1] a solid 1.0 API around the top features to get the
> ball rolling and will iterate on these going forward.
>
> Apple has outlined guidelines and best practices[1] for the Touch Bar
> that are good to keep in mind. Here are some of the most important
> points to consider:
> 1. Design a contextual experience. Make the Touch Bar relevant to the
> current context on the main screen.
> 2. Use the Touch Bar as an extension of the keyboard and trackpad, not
> as a display.
> 3. **Don’t expose functionality solely in the Touch Bar.
> 4. Avoid using the Touch Bar for tasks associated with well-known
> keyboard shortcuts.
>
> -Stephen
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313455
> [2]
> https://developer.apple.com/library/content/documentation/
> UserExperience/Conceptual/OSXHIGuidelines/AbouttheTouchBar.html#//apple_
> ref/doc/uid/2957-CH104-SW1
> ___
> 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: Ambient Light Sensor API

[Haik Aftandilian]

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 04/25/2017 08:26 PM, Salvador de la Puente wrote:
>
>> So the risk is not that high since if the image is not protected I can
>> get it and do evil things without requiring the Light Sensor API. Isn't it?
>>
>
> No, the risk is extremely high.
>
> Here is a concrete example.  Some banks give their users scanned copies of
> their cheques (including secret financial information) as cookie protected
> images.  Browsers already have protections in place that prevent
> cross-origin pages from reading the pixel values of these images by
> tainting such images and remembering that an image is coming from such a
> source and preventing the contents of such a tainted image to be read out
> through an API that gives you access to raw pixel values.  Merely uploading
> the URL of such an image to the evil.com server doesn't help the attacker
> since they won't have access to the user's credentials on the server side.
> The attack vector being discussed here introduces a new vulnerability
> vector for websites to try to steal sensitive information like this in ways
> that currently isn't possible.
>
>
>> On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla > e...@rtfm.com>> wrote:
>>
>>
>>
>> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente
>> mailto:sdelapue...@mozilla.com>> wrote:
>>
>> The article says:
>>
>> Embed an image from the attacked domain; generally this will
>> be a resource
>> > which varies for different authenticated users such as the
>> logged-in user’s
>> > avatar or a security code.
>> >
>>
>> And then refers all the steps to this image (binarizing,
>> expand and measure
>> per pixel) but, If I can embed that image, it is because I
>> know the URL for
>> it and the proper auth tokens if it is protected. In that
>> case, why to not
>> simply steal the image?
>>
>>
>> The simple version of this is that the image is cookie protected.
>>
>> -Ekr
>>
>>
>> On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston
>> mailto:j...@mozilla.com>> wrote:
>>
>> > Auth related images are the attack vector, that and history
>> attacks on
>> > same domain.
>> >
>> > On Tue, Apr 25, 2017 at 11:17 PM, Salvador de la Puente <
>> > sdelapue...@mozilla.com >
>> wrote:
>> >
>> >> Sorry for my ignorance but, in the case of Stealing
>> cross-origin
>> >> resources,
>> >> I don't get the point of the attack. If have the ability to
>> embed the
>> >> image
>> >> in step 1, why to not simply send this to evil.com
>>  for further
>> >> processing?
>> >> How it is possible for evil.com  to get
>> access to protected resources?
>> >>
>> >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari
>> mailto:ehsan.akhg...@gmail.com>>
>> >> wrote:
>> >>
>> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
>> >> >
>> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla
>> mailto:e...@rtfm.com>> wrote:
>> >> >>
>> >> >> Going back to Jonathan's (I think) question. Does anyone
>> use this at
>> >> all
>> >> >>> in
>> >> >>> the field?
>> >> >>>
>> >> >>> Chrome's usage metrics say <= 0.0001% of page loads:
>> >> >>
>> https://www.chromestatus.com/metrics/feature/popularity#Ambi
>> 
>> >> >> entLightSensorConstructor.
>> >> >>
>> >> >
>> >> > This is the new version of the spec which we don't ship.
>> >> >
>> >> >
>> >> > We are going to collect telemetry in
>> >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124
>> .
>> >> >> ___
>> >> >> 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: Enabling filesystem read-restrictions for content process sandbox

[Haik Aftandilian]

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 file descriptor is sent to the content process where the
> reading happens.
> Is this supported yet?
>

​Yes, reading from a file descriptor opened in the parent should continue
to work.

Haik​



>
> On Fri, Jul 21, 2017 at 3:44 PM,  wrote:
>
> > As a follow-up to this, tomorrow's (2017-07-22) Nightly will have this
> > enabled for the Windows content process sandbox as well.
> >
> > On Windows this removes access that the User gains via their own SID.
> > So generally things under their home directory (C:\Users\\).
> > With exceptions for the Firefox installation directory and the chrome
> > directory in the profile.
> >
> > There are a few other restrictions included as well, for example reading
> > and writing to the clipboard.
> >
> > If you hit any issues on Windows after tomorrow that disappear when you
> > set the pref security.sandbox.content.level to 2 or lower, please file a
> > bug to block https://bugzilla.mozilla.org/show_bug.cgi?id=1366697.
> >
> > Cheers,
> > Bob
> >
> >
> > On Thursday, 6 July 2017 15:07:50 UTC+1, Alex Gaynor  wrote:
> > > Hi dev-platform,
> > >
> > > On behalf of the Runtime Content Isolation (aka sandboxing) team, I'm
> > > delighted
> > > to announce that starting later this week, our macOS and Windows
> nightly
> > > builds
> > > will prohibit read access to most of the filesystem in the content
> > process!
> > >
> > > What does this mean for you? First and foremost, a more secure browser!
> > > Second,
> > > it means that if you see bugs, please report them, our goal is to put
> > this
> > > on
> > > the trains for 56! If you run into anything, please file it as a
> blocker
> > for
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1377522 .
> > >
> > > Finally, it means that in code you're writing, you should not expect to
> > be
> > > able
> > > to read from the filesystem in the content process -- with the
> exception
> > of
> > > inside the .app bundle, or in the chrome/ subdirectory of the profile
> > > directory.
> > >
> > > If you need access to a file in content, you should plan on remoting
> that
> > > to the
> > > parent process. When designing these APIs, please be careful to ensure
> > the
> > > parent process is able to perform appropriate permissions checks such
> > that
> > > the
> > > IPC mechanism isn't able to bypass the sandbox's goal of preventing a
> > > malicious
> > > content process from accessing the entire file system.
> > >
> > > This represents the culmination of a lot of work by a lot of folks,
> both
> > on
> > > our
> > > team and on many other teams who helped out with refactoring their code
> > --
> > > thank
> > > you!
> > >
> > > We're looking forward to also shipping this for Linux soon.
> > >
> > > Cheers,
> > > Alex
> >
> > ___
> > 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: Commit messages in Phabricator

[Haik Aftandilian]

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 first line of the commit message is
essential when looking at hg log output and I think maintaining that is
important. Having the reviewers is also useful.

Haik



>
> -Ekr
>
>
> >
> > -Boris
> >
> > ___
> > 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

Intent to ship: macOS Flash NPAPI Sandbox

[Haik Aftandilian]

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
dom.ipc.plugins.sandbox-level.flash=1 and restarting the browser[2]. Before
this rides the trains, we intend to offer a per-site opt-out UI. But we
will enable this on Nightly by default earlier to get early feedback.

If you run Firefox on Mac and depend on any Flash sites, please give the
site a try with the sandbox enabled. And if you encounter any issues,
please file bugs blocking bug 1433577[3].

Thanks,
Haik

1. Flash applets that attempt to write to the filesystem will be impacted
because the plugin process has limited write access. Adobe Air installs
triggered by Flash applets will no longer work. Printing to PDF or
postscript, and Open in Preview from the print dialog does not work. No
issues have been found with any Flash games.

2. The same pref is used on Windows, but the numerical levels are not
comparable or related in any way to the Mac version.

3. https://bugzilla.mozilla.org/show_bug.cgi?id=1433577
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: macOS Flash NPAPI Sandbox

[Haik Aftandilian]

On Tue, Mar 20, 2018 at 10:54 AM, Haik Aftandilian  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 functionality[1]. You can enable the sandbox now
> on Nightly, globally for all sites, by setting
> dom.ipc.plugins.sandbox-level.flash=1 and restarting the browser[2].
> Before this rides the trains, we intend to offer a per-site opt-out UI. But
> we will enable this on Nightly by default earlier to get early feedback.
>

The Mac Flash sandbox is
​now ​
enabled by default on Nightly.

​Thanks,
Haik
​

>
> If you run Firefox on Mac and depend on any Flash sites, please give the
> site a try with the sandbox enabled. And if you encounter any issues,
> please file bugs blocking bug 1433577[3].
>
> Thanks,
> Haik
>
> 1. Flash applets that attempt to write to the filesystem will be impacted
> because the plugin process has limited write access. Adobe Air installs
> triggered by Flash applets will no longer work. Printing to PDF or
> postscript, and Open in Preview from the print dialog does not work. No
> issues have been found with any Flash games.
>
> 2. The same pref is used on Windows, but the numerical levels are not
> comparable or related in any way to the Mac version.
>
> 3. https://bugzilla.mozilla.org/show_bug.cgi?id=1433577
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Haik Aftandilian]

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 out.  So a bisect task that might otherwise take 10-15 minutes
>> total (1 minute per downloaded build) ends up taking hours...
>>
>
> I've found it pretty difficult to build old versions once past a couple of
> months. Different version of rustc, dev tools not yet supported
> (particularly on Windows with requirements to always use the last version
> of Visual Studio
>

​Just a note about using an older version of rustc: the "rustup override"
command can be used to downgrade the rust toolchain for a given repo while
not affecting the version that is used on the rest of the system. That can
be handy when trying to build older trees.

Haik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Haik Aftandilian]

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 Marco's concern, increasing timeouts has the side
effect where performance regressions are not noticed. i.e., a new bug that
causes a test to take longer, but still pass, is not detected. With the
original lower timeouts, the test would fail with a timeout. So a little
bit of the value of the tests is lost, and it's difficult to address later.

Haik


>
> I think that's the main reason the default timeout was set to a low value,
> while still allowing the multipliers as a special case for tests that
> really require bigger times, cause there's no other way out.
>
> Is docker doubling the time for every test? From the bug looks like it may
> add 20-30% of overhead, so why are we not bumping the timeout of 30% (let's
> say 60s) and investigating the original cause (the bug that takes 80s to
> run) to figure if something can be done to make it finish sooner?
>
> -m
>
>
> On Mon, Feb 8, 2016 at 11:51 PM, Armen Zambrano G. 
> wrote:
>
> > Hello,
> > In order to help us have less timeouts when running mochitests under
> > docker, we've decided to double mochitests' gTimeoutSeconds and reduce
> > large multipliers in half.
> >
> > Here's the patch if you're curious:
> >
> >
> https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1246152&attachment=8717111
> >
> > If you have any comments or concerns please raise them in the bug.
> >
> > regards,
> > Armen
> >
> > --
> > Zambrano Gasparnian, Armen
> > Automation & Tools Engineer
> > http://armenzg.blogspot.ca
> > ___
> > 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: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Haik Aftandilian]

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:
>
> * Security: login cookies set over non-secure HTTP can be sniffed and
> replayed. Clearing those cookies at the end of the browser session would
> force the user to log in again next time, reducing the window of
> opportunity for an attacker to replay the login cookie. To avoid this,
> login-requiring sites should use HTTPS for at least their login page that
> set the login cookie.
>

​Wouldn't that only be true for sites that limit users to one login session
at a time? For sites that allow more than one login session​, when the user
logs in again each time, the original session cookie would not be
invalidated until the site decides to forget it. So if an attacker sniffed
the login cookie, they could replay it even after the user logged in again.
I know I have persistent logins to some sites on more than one computer,
but don't know how typical that is.

Haik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Haik Aftandilian]

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 his original post, Henri argued that clearing non-HTTPS cookies between
> sessions would not "Break the Web". There would be no user- or
> site-detectable changes mid-session. Clearing cookies between sessions
> could be user-detectable if they get logged out or lose their shopping
> cart. Sites, OTOH, must already handle the cases were a user's cookies are
> lost between sessions. Users could clear their cookies, use Private
> Browsing mode, or log into the site from a different browser or device.
>

​Tanvi brought up this point.

On Thu, Apr 14, 2016 at 12:58 PM, Tanvi Vyas  wrote:
​...​
* Even if login cookies are set over HTTPS, there are sometimes additional
cookies set over HTTP with user data in them (ex: city/zipcode).  Users may
have bad experiences on websites that rely on these secondary HTTP cookies
even if they are still logged in (ex: weather.yahoo.com for a user who is
logged into yahoo.com).
​...​

Sites might depend on a combination of https and non-https cookies and then
act strangely when a user returns to the site with only the https cookies.

Haik​

​​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

OS X Nightly Content Sandbox Changes

[Haik Aftandilian]

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
Console application where you can filter on "plugin-container" or "sandbox"
and look for deny log entries.

You can also experiment with disabling the content sandbox on OS X Nightly
by setting the preference security.sandbox.content.level=0.

File bugs with product=Core and component=Security: Process Sandboxing.

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1272772

Thanks,
Haik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Heads Up: Mac CFMessagePort/CFPasteboardSetup Error Messages

[Haik Aftandilian]

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 restrictions imposed on content processes.
​ I filed bug 1306663[2] to track the work to remove the messages. More
context on 1299329​ for those interested.​


plugin-container[96229:2989903] *** CFMessagePort: bootstrap_register():
failed 1100 (0x44c) 'Permission denied', port = 0x4b2f, name =
'com.apple.tsm.portname'
See /usr/include/servers/bootstrap_defs.h for the error codes.

plugin-container[96229:2989903] void __CFPasteboardSetup() : Failed to
allocate communication port for com.apple.CFPasteboardClient; this is
likely due to sandbox restrictions

​1. ​*Bug 1299329*
 - Remove
printing-related privileges from content process sandbox
2. *Bug 1306663*
 - Investigate
Preventing OS X CFMessagePort/CFPasteboardSetup Error Messages

​Thanks,
Haik​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Haik Aftandilian]

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 configured your builds to use an older SDK and not the
default XCode install, you will not be affected.

Haik

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1492210
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Haik Aftandilian]

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
> 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 configured your builds to use an older SDK and
> not the default XCode install, you will not be affected.
>
> Haik
>
> 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1492210
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New macOS mach run option: --macos-open

[Haik Aftandilian]

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, "the open command opens a file (or a directory or
URL), just as if you had double-clicked the file's icon." One big
difference is that the application is spawned directly by the launchd
process instead of via the shell parent process chain.

There is no support for using this with tests, but there is an argument to
be made that our testing would be more representative of real world use if
we started the browser in the same way that users do. That would require
reworking tests to wait for the correct browser process to exit and somehow
collecting stdout/stderr output. That might be something we do in the
future if the option ends up being useful.

One use I've found for this relates to the new macOS 10.14 Mojave device
permission dialogs for the camera/mic. When launched via "mach run", the
dialog is displayed as '"Terminal" would like to access the camera." (I
consider that a macOS limitation and not a Firefox bug.) When launching
with the open command, the dialog is displayed correctly.

Thanks,
Haik

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1494326
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Apple Notary Service and Debugging Impact

[Haik Aftandilian]

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 users have to click through to start the
application is less of a warning.

We are working on adopting the service on bug 1470607, but I wanted to
share how this will affect debugging and get some feedback. If an
application is "notarized", starting with macOS 10.14, the OS will prevent
debuggers from attaching to the application unless the user has disabled
macOS system integrity protection (SIP)[4] which requires a reboot. This
prevents debugging of the application with a debugger like lldb or gdb on a
default system.

Assuming the debugging restriction will _not_ apply to the Nightly channel,
local builds, or automation builds, will this debugging
restriction+workaround on official builds (Release, Beta, DevEd) be a
problem for your workflow or in any way you can envision?

Apple has stated that signing with the notary service will be required in a
future macOS version. I think we can assume that this means an application
that is not notarized will require special steps for first launch where the
user may also have to click through dire security warnings. Today,
launching Firefox for the first time on Mac already requires clicking
through one warning. The bug includes a screenshot[3] showing how it will
change with notarized builds.

Thanks,
Haik

1.
https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
2. Using the service A) submits the application to Apple to run malware
checks on the binaries and B) requires setting some executable security
flags known as Hardened Runtime. At present, Firefox mostly does not
benefit from enabling Hardened Runtime for various reasons. Another benefit
relates to how a single version of the application can be revoked, without
having to revoke all versions signed with the same key.
3. https://bug1470607.bmoattachments.org/attachment.cgi?id=9036014
4. https://support.apple.com/en-us/HT204899
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Apple Notary Service and Debugging Impact

[Haik Aftandilian]

Update on our adoption of Notary Service and its debugging impact:

With notarization, Nightly channel builds will not be debuggable unless the
system is booted with system integrity protection (SIP)[1] disabled. In my
earlier mail[2] to dev-platform about our adoption of the Notary Service, I
indicated that Nightly channel builds would not be impacted by the
debugging restrictions. Since that time we've learned that it is not
possible to notarize an app unless the debugging restrictions are enabled
hence notarizing official Nightly channel builds will prevent debugging of
the app unless the system is booted with SIP disabled. As a result, our
plan is to notarize Nightly channel builds in the same way we will for Beta
and Release.

We could choose to skip notarization of the Nightly channel builds to allow
for easier debugging, but then we lose the testing and validation we get
from Nightly for notarization. Nightly's update cadence is also valuable
for validating notarized updates. We could revisit this decision in the
future and choose to opt-out of notarization for Nightly channel builds if
we find the debugging restriction to be blocking important debugging
efforts. That decision would also depend on how difficult installing
non-notarized apps is in future macOS versions (which is unknown at this
time) and how much extra complexity this adds to our release process.

The feedback I received from Mac developers at Mozilla was that it was a
rare occurrence to need to debug an official channel build. Developers are
more likely debug their own builds (with a more debug-friendly build
config.)

Lastly, Apple recently updated their documentation[3] to say that in "macOS
10.14.5, all new or updated kernel extensions and all software from
developers new to distributing with Developer ID must be notarized in order
to run. In a future version of macOS, notarization will be required by
default for all software."

Thanks,
Haik

1. https://support.apple.com/en-us/HT204899
2. https://lists.mozilla.org/pipermail/dev-platform/2019-January/023337.html
3.
https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

On Mon, Jan 14, 2019 at 10:54 AM Stephen A Pohl  wrote:

> FWIW, I tend to debug local builds of these individual branches to make
> my life easier, for example by turning optimization off etc. It has only
> 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 1/11/19 6:36 PM, Haik Aftandilian wrote:
> > 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 users have to click through to start the
> > application is less of a warning.
> >
> > We are working on adopting the service on bug 1470607, but I wanted to
> > share how this will affect debugging and get some feedback. If an
> > application is "notarized", starting with macOS 10.14, the OS will
> prevent
> > debuggers from attaching to the application unless the user has disabled
> > macOS system integrity protection (SIP)[4] which requires a reboot. This
> > prevents debugging of the application with a debugger like lldb or gdb
> on a
> > default system.
> >
> > Assuming the debugging restriction will _not_ apply to the Nightly
> channel,
> > local builds, or automation builds, will this debugging
> > restriction+workaround on official builds (Release, Beta, DevEd) be a
> > problem for your workflow or in any way you can envision?
> >
> > Apple has stated that signing with the notary service will be required
> in a
> > future macOS version. I think we can assume that this means an
> application
> > that is not notarized will require special steps for first launch where
> the
> > user may also have to click through dire security warnings. Today,
> > launching Firefox for the first time on Mac already requires clicking
> > through one warning. The bug includes a screenshot[3] showing how it will
> > change with notarized builds.
> >
> > Thanks,
> > Haik
> >
> > 1.
> >
> https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
> > 2. Using the service A) submits the application to Apple to run malware
> > checks on the binaries and B) requires setting some executable security
>

Re: Apple Notary Service and Debugging Impact

[Haik Aftandilian]

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 know whether sampling via Activity Monitor's "Sample Process"
> option or via Instruments will still work?
>

Yes. In my testing the sampling options in Activity Monitor continue to
work and I've done some limited testing with Instruments which seemed to
work. I would expect this to be a requirement and to still be supported,
but I'll ask if our Apple contact can confirm this.

And I can send you a notarized Nightly build if you'd like to test a
particular sampling/instrumentation.

Thanks,
Haik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Heads Up: Apple Notarized Nightly Builds

[Haik Aftandilian]

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 adapt our release pipeline to
support Notarization, especially from Aki Sasaki and Nick Thomas.

What you need to know as a Firefox Mac developer:

I) Hardened Runtime and Notarization are not enabled for local builds so
there is no impact to debugging of local builds. We have a bug filed[2] to
enable Hardened Runtime on local builds, but this should not affect
debugging because the debugging restriction only applies to Notarized
applications.

II) Debugging a Nightly channel build will require disabling Mac System
Integrity Protection[3] (SIP). Nightly channel builds will be signed with
the Hardened Runtime entitlements from the production.entitlements.xml file
from the tree.

III) try push builds will be signed with Hardened Runtime enabled using the
entitlements from the developer.entitlements.xml file from the tree and
should be debuggable as before.

For bugs found that appear to be caused by this change, please file under
Core/Widget: Cocoa.

Haik

1.
https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
2.
https://groups.google.com/d/msg/mozilla.dev.platform/4VvbvY1Brnw/DWYlj8rhDAAJ
3. https://bugzilla.mozilla.org/show_bug.cgi?id=1522409
4. https://support.apple.com/en-us/HT204899
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads Up: Apple Notarized Nightly Builds

[Haik Aftandilian]

I've updated our "Debugging on Mac OS X" MDN page with some information
about debugging Mac builds with Notarization and Hardened Runtime
restrictions.

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_on_Mac_OS_X#Debugging_Firefox_on_macOS_10.14

Let me know if you 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.
>
> First, I want to recognize that this required a very significant amount of
> work from the Release Engineering team to adapt our release pipeline to
> support Notarization, especially from Aki Sasaki and Nick Thomas.
>
> What you need to know as a Firefox Mac developer:
>
> I) Hardened Runtime and Notarization are not enabled for local builds so
> there is no impact to debugging of local builds. We have a bug filed[2] to
> enable Hardened Runtime on local builds, but this should not affect
> debugging because the debugging restriction only applies to Notarized
> applications.
>
> II) Debugging a Nightly channel build will require disabling Mac System
> Integrity Protection[3] (SIP). Nightly channel builds will be signed with
> the Hardened Runtime entitlements from the production.entitlements.xml file
> from the tree.
>
> III) try push builds will be signed with Hardened Runtime enabled using
> the entitlements from the developer.entitlements.xml file from the tree and
> should be debuggable as before.
>
> For bugs found that appear to be caused by this change, please file under
> Core/Widget: Cocoa.
>
> Haik
>
> 1.
> https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
> 2.
> https://groups.google.com/d/msg/mozilla.dev.platform/4VvbvY1Brnw/DWYlj8rhDAAJ
> 3. https://bugzilla.mozilla.org/show_bug.cgi?id=1522409
> 4. https://support.apple.com/en-us/HT204899
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform