Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

2016-08-30 Thread Brunoais 
Does team viewer's quick connect button continue working in firefox 
windows after that?



On 30-08-2016 16:44, Benjamin Smedberg wrote:
This is notice of an intent to change how we export symbols from the 
Firefox DLLs and binaries.


Currently our policy is that extensions may not include binary XPCOM 
components, and we've implemented some very basic rules that make it 
difficult for extensions to load these components. However, there is 
3rd-party software that continues to use binary XPCOM: either by 
loading DLLs using ctypes and then using XPCOM, or injecting DLLs into 
the Firefox process.


Binary injection has been the cause of numerous crash issues in 
Firefox, which commonly show up as startup crashes when a Firefox 
update is first run. I believe that solving these crashes is a 
critical part of our Firefox quality story and our ability to release 
Firefox updates in a timely manner.


To that end, I believe that we should make it technically impossible 
for external DLLs to use XPCOM. I propose to do this in the following way:


Integrate the remaining Firefox binary component back into xul.dll 
using internal linkage.


Remove the XPCOM glue. This will involve reworking a little bit of how 
firefox.exe and plugin-container.exe initially load and launch gecko 
from xul.dll.


Remove most of the XPCOM-related xul.dll exports, and as many other 
exports as possible.
This includes all of the mozilla::services exports, as well as things 
like NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the 
XRE_ functions like XRE_AddManifestLocation.


Undecided: whether we can or need to remove the "frozen XPCOM string 
API" exports. I'd like to, but it's not strictly necessary to solve 
the primary stability issues of external code using binary XPCOM, and 
I'm not sure what it would affect or how hard it will be.


I have prepared a list of current xul.dll exports from a recent 
nightly build, and proposed mitigations with bug numbers: 
https://docs.google.com/spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp=sharing


It is likely that this project will affect Thunderbird and/or 
SeaMonkey, but I'm not sure in what ways. My understanding is that 
Thunderbird currently builds with internal linkage. I plan to keep 
Thunderbird informed of the work here, and accepting patches that help 
Thunderbird stay building, but I do not intend to significantly delay 
or WONTFIX this Firefox work for Thunderbird.


https://bugzilla.mozilla.org/show_bug.cgi?id=1299187 is the tracking bug.

Please direct followup comments & questions to dev-platform.

--BDS


___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev


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

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

2016-08-30 Thread Ehsan Akhgari 
On 2016-08-30 11:44 AM, Benjamin Smedberg wrote:
> This is notice of an intent to change how we export symbols from the
> Firefox DLLs and binaries.
> 
> Currently our policy is that extensions may not include binary XPCOM
> components, and we've implemented some very basic rules that make it
> difficult for extensions to load these components. However, there is
> 3rd-party software that continues to use binary XPCOM: either by loading
> DLLs using ctypes and then using XPCOM, or injecting DLLs into the
> Firefox process.
> 
> Binary injection has been the cause of numerous crash issues in Firefox,
> which commonly show up as startup crashes when a Firefox update is first
> run. I believe that solving these crashes is a critical part of our
> Firefox quality story and our ability to release Firefox updates in a
> timely manner.
> 
> To that end, I believe that we should make it technically impossible for
> external DLLs to use XPCOM.

Can you please clarify why this proposal is around preventing external
DLLs from using XPCOM?  In my experience, a good number of the DLLs
different programs inject into Firefox are injected using the several
facilities that Windows provides for this task, and whether or not those
DLLs get access to the symbols currently exported from xul.dll, they can
still cause a lot of harm.  I'm trying to understand how removing the
XPCOM functions they can link against dynamically will improve our
situation.

Thanks,
Ehsan

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

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

2016-08-30 Thread Mike Hommey 
On Tue, Aug 30, 2016 at 11:44:35AM -0400, Benjamin Smedberg wrote:
> This is notice of an intent to change how we export symbols from the
> Firefox DLLs and binaries.
> 
> Currently our policy is that extensions may not include binary XPCOM
> components, and we've implemented some very basic rules that make it
> difficult for extensions to load these components. However, there is
> 3rd-party software that continues to use binary XPCOM: either by loading
> DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox
> process.
> 
> Binary injection has been the cause of numerous crash issues in Firefox,
> which commonly show up as startup crashes when a Firefox update is first
> run. I believe that solving these crashes is a critical part of our Firefox
> quality story and our ability to release Firefox updates in a timely manner.
> 
> To that end, I believe that we should make it technically impossible for
> external DLLs to use XPCOM. I propose to do this in the following way:
> 
> Integrate the remaining Firefox binary component back into xul.dll using
> internal linkage.

If we do this, we could as well reconsider the separation of browser and
GRE files. Firefox is the only gecko-based application that does it. It
was introduced for the metro UI, used by the webapp runtime, and was
useful to ensure xulrunner toolkit files weren't trying to use Firefox
files through resource://gre. None of metro, webapprt or xulrunner are
a thing anymore. There's still a risk for toolkit using resource://gre
urls for Firefox resources, though, and that can impact
Thunderbird/Seamonkey/other third-party XUL apps.
 
> Remove the XPCOM glue. This will involve reworking a little bit of how
> firefox.exe and plugin-container.exe initially load and launch gecko from
> xul.dll.

With all the stuff repeated between various nsBrowserApp.cpp-like files,
with different level of support for the latest things in non-Firefox,
this is more than welcome. That's something that I've been meaning to do
for a long while, but this never reached a high enough priority to make
it out of my TODO.

> Remove most of the XPCOM-related xul.dll exports, and as many other exports
> as possible.
> This includes all of the mozilla::services exports, as well as things like
> NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the XRE_
> functions like XRE_AddManifestLocation.
> 
> Undecided: whether we can or need to remove the "frozen XPCOM string API"
> exports. I'd like to, but it's not strictly necessary to solve the primary
> stability issues of external code using binary XPCOM, and I'm not sure what
> it would affect or how hard it will be.

If there aren't XPCOM binary components, I don't see what difference it
would make if the XPCOM string API is exported or not. In fact, it could
be removed, nothing should be using it through internal linkage.
(And here, I really mean not-built, since it might be necessary to keep
for comm-central)

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

Usability improvements for Firefox automation initiative - Status update #4

2016-08-30 Thread Armen Zambrano 
Hello,
On this update we will look at the progress made in the last two weeks.

A reminder that this quarter’s main focus is on:
Debugging tests on interactive workers (only Linux on TaskCluster)
Improve end to end times on Try (Thunder Try project)

For all bugs and priorities you can check out the project management
page for it:
https://wiki.mozilla.org/EngineeringProductivity/Projects/Debugging_UX_improvements

Status update:
Debugging tests on interactive workers
---
Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262260

Accomplished recently:
* Landed support for |mach marionette-test| on loaner
* Fixed xpcshell bug where specifying a path didn’t work

Upcoming:
* Support for Android jobs (starting with mochitest)


Thunder Try - Improve end to end times on try
-

Project #1 - Artifact builds on automation
##
Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1284882

Accomplished recently:
* Implemented (not yet landed) ‘-artifact’ flag in try syntax which
replaces full build step with artifact build. Desktop Linux64 working so
far; will land once also working on Win/OS X.

Upcoming:
* Restrict -artifact try flag to requests that don’t involve
compiled-code tests

Project #2 - S3 Cloud Compiler Cache

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280641

Nothing new for this edition.

Project #3 - Metrics

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1286856

Accomplished recently:
* Working on Infraherder RFC, incorporating comments and feedback

Upcoming:
* Working on expanding prototype to work dynamically with more repositories
* Experimenting with using ActiveData to query for data
* Scope work based on Infraherder RFC

Other
#
Bug 1272083 - Downloading/unzipping to be performed in memory
* Having issues on e10s Win7 crashtests with
EXCEPTION_ACCESS_VIOLATION_WRITE

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

Re: Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

2016-08-30 Thread funcod 
> - Bail out on web fonts with an effectively slow connection

This is terrible and error prone for sure. Hopefully Mozilla won't follow suit.

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

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

2016-08-30 Thread R Kent James 
On 8/30/2016 8:44 AM, Benjamin Smedberg wrote:

> It is likely that this project will affect Thunderbird and/or SeaMonkey,
> but I'm not sure in what ways. My understanding is that Thunderbird
> currently builds with internal linkage. I plan to keep Thunderbird informed
> of the work here, and accepting patches that help Thunderbird stay
> building, but I do not intend to significantly delay or WONTFIX this
> Firefox work for Thunderbird.

Thunderbird 45 (based on m-esr45) has allowed binary extensions, but we
have agreed for some months now that Thunderbird 52 will no longer
support binary extensions. The extensions are currently only used by
addons closely closely connected to the core project. Even at TB 45
there were significant changes in m-c that made using a binary extension
very challenging, and the assumption has been that ongoing changes, such
as the ones you are suggesting here, would make that impossible. I am
not aware of any existing parts of shipping Thunderbird that use
external linkage, but if there are any that would be something that
needs removing or fixing.

That being said, there has been some pushback on this due to the
performance costs of using JS instead of C++. If major breaking changes
could be delayed until Gecko 53, or if it was possible to have some
build options that would allow external linkage as an option, that would
be good. But we could live without it.

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

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

2016-08-30 Thread Benjamin Smedberg 
On Tue, Aug 30, 2016 at 12:16 PM, Gregory Szorc  wrote:

>
> To clarify, are you proposing a) removing all support for exporting XPCOM
> symbols from libxul full stop or b) changing the shipping configuration of
> Firefox to not export these symbols?
>

b) is the minimum option for Firefox.

I think a) is the better option, and I'd like to try it: assuming I'm right
about thunderbird using internal linkage, I don't see any reason we need to
keep exporting these symbols at all.

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

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

2016-08-30 Thread Gregory Szorc 
On Tue, Aug 30, 2016 at 8:44 AM, Benjamin Smedberg 
wrote:

> This is notice of an intent to change how we export symbols from the
> Firefox DLLs and binaries.
>
> Currently our policy is that extensions may not include binary XPCOM
> components, and we've implemented some very basic rules that make it
> difficult for extensions to load these components. However, there is
> 3rd-party software that continues to use binary XPCOM: either by loading
> DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox
> process.
>
> Binary injection has been the cause of numerous crash issues in Firefox,
> which commonly show up as startup crashes when a Firefox update is first
> run. I believe that solving these crashes is a critical part of our Firefox
> quality story and our ability to release Firefox updates in a timely manner.
>
> To that end, I believe that we should make it technically impossible for
> external DLLs to use XPCOM. I propose to do this in the following way:
>
> Integrate the remaining Firefox binary component back into xul.dll using
> internal linkage.
>
> Remove the XPCOM glue. This will involve reworking a little bit of how
> firefox.exe and plugin-container.exe initially load and launch gecko from
> xul.dll.
>
> Remove most of the XPCOM-related xul.dll exports, and as many other
> exports as possible.
> This includes all of the mozilla::services exports, as well as things like
> NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the XRE_
> functions like XRE_AddManifestLocation.
>
> Undecided: whether we can or need to remove the "frozen XPCOM string API"
> exports. I'd like to, but it's not strictly necessary to solve the primary
> stability issues of external code using binary XPCOM, and I'm not sure what
> it would affect or how hard it will be.
>
> I have prepared a list of current xul.dll exports from a recent nightly
> build, and proposed mitigations with bug numbers: https://docs.google.com/
> spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp=
> sharing
>
> It is likely that this project will affect Thunderbird and/or SeaMonkey,
> but I'm not sure in what ways. My understanding is that Thunderbird
> currently builds with internal linkage. I plan to keep Thunderbird informed
> of the work here, and accepting patches that help Thunderbird stay
> building, but I do not intend to significantly delay or WONTFIX this
> Firefox work for Thunderbird.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1299187 is the tracking bug.
>
> Please direct followup comments & questions to dev-platform.
>

To clarify, are you proposing a) removing all support for exporting XPCOM
symbols from libxul full stop or b) changing the shipping configuration of
Firefox to not export these symbols?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to harden binary injection by removing XPCOM and related xul.dll exports

2016-08-30 Thread Benjamin Smedberg 
This is notice of an intent to change how we export symbols from the
Firefox DLLs and binaries.

Currently our policy is that extensions may not include binary XPCOM
components, and we've implemented some very basic rules that make it
difficult for extensions to load these components. However, there is
3rd-party software that continues to use binary XPCOM: either by loading
DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox
process.

Binary injection has been the cause of numerous crash issues in Firefox,
which commonly show up as startup crashes when a Firefox update is first
run. I believe that solving these crashes is a critical part of our Firefox
quality story and our ability to release Firefox updates in a timely manner.

To that end, I believe that we should make it technically impossible for
external DLLs to use XPCOM. I propose to do this in the following way:

Integrate the remaining Firefox binary component back into xul.dll using
internal linkage.

Remove the XPCOM glue. This will involve reworking a little bit of how
firefox.exe and plugin-container.exe initially load and launch gecko from
xul.dll.

Remove most of the XPCOM-related xul.dll exports, and as many other exports
as possible.
This includes all of the mozilla::services exports, as well as things like
NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the XRE_
functions like XRE_AddManifestLocation.

Undecided: whether we can or need to remove the "frozen XPCOM string API"
exports. I'd like to, but it's not strictly necessary to solve the primary
stability issues of external code using binary XPCOM, and I'm not sure what
it would affect or how hard it will be.

I have prepared a list of current xul.dll exports from a recent nightly
build, and proposed mitigations with bug numbers:
https://docs.google.com/spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp=sharing

It is likely that this project will affect Thunderbird and/or SeaMonkey,
but I'm not sure in what ways. My understanding is that Thunderbird
currently builds with internal linkage. I plan to keep Thunderbird informed
of the work here, and accepting patches that help Thunderbird stay
building, but I do not intend to significantly delay or WONTFIX this
Firefox work for Thunderbird.

https://bugzilla.mozilla.org/show_bug.cgi?id=1299187 is the tracking bug.

Please direct followup comments & questions to dev-platform.

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

Re: [Firefox Desktop] Issues found: August 22nd to 26th

2016-08-30 Thread Andrei Vaida 

Hi Coda Coder,

This kind of reports only include the bugs filed by the Desktop Release 
QA Team, always for the previous week.


Best,
Andrei

On 8/30/2016 3:53 PM, Coda Coder wrote:

Hi

Just so I can understand these posts, what kind of issues are included 
(and, thereby, excluded)?  Why, for example, would...


https://bugzilla.mozilla.org/show_bug.cgi?id=1298065(Regression - 
Nightly does not remember Privacy History settings correctly)


not be included? It was found and reported on the 25th (pre 26th), 
affects user privacy (to be considered "major" I'd have thought) and 
is clearly a "regression" which appeared very recently.


Thanks


From: andrei.va...@softvisioninc.eu
Subject: [Firefox Desktop] Issues found: August 22nd to 26th
To: firefox...@mozilla.org; dev-platform@lists.mozilla.org; 
firefox-...@mozilla.org; fx-m...@mozilla.com; user-advoc...@mozilla.com

Date: Mon, 29 Aug 2016 16:25:46 +0300

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release 
QA Team last week, *August 22 - August 26* (week 34).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus


*RELEASE CHANNEL*
none
/*
*/*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1297632 
[OSX 10.12] Safe Browsing Phising warning is not displayed
Toolkit
Safe Browsing
NO  NOBODY


*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1298027 
	[EME] Video is crashing on Shaka Player Demo page when is moved into 
New window

Core
Audio/Video: Playback
NO  Bryce Van Dyk
1298030 
[EME] Video is stuck on Youtube when is moved into New window
Core
Audio/Video: Playback
NO  Bryce Van Dyk


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1297040 
WebRTC permission doorhanger doesn't appear while RDM is enabled
Firefox
Developer Tools: Responsive Design Mode
NO  NOBODY
1297336 
	Device permission gone from the permission dropdown after detaching 
the tab to a new window

Firefox
Device Permissions
YES NOBODY


*ESR CHANNEL*
none


Regards,
Andrei

___ firefox-dev mailing 
list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev



___
Firefox-qe mailing list
firefox...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-qe


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

RE: [Firefox Desktop] Issues found: August 22nd to 26th

2016-08-30 Thread Coda Coder 
Hi 

Just so I can understand these posts, what kind of issues are included (and, 
thereby, excluded)?  Why, for example, would...

  https://bugzilla.mozilla.org/show_bug.cgi?id=1298065 (Regression - Nightly 
does not remember Privacy History settings correctly)

not be included? It was found and reported on the 25th (pre 26th), affects user 
privacy (to be considered "major" I'd have thought) and is clearly a 
"regression" which appeared very recently.

Thanks

From: andrei.va...@softvisioninc.eu
Subject: [Firefox Desktop] Issues found: August 22nd to 26th
To: firefox...@mozilla.org; dev-platform@lists.mozilla.org; 
firefox-...@mozilla.org; fx-m...@mozilla.com; user-advoc...@mozilla.com
Date: Mon, 29 Aug 2016 16:25:46 +0300


  


  
  
Hi everyone,



Here's the list of new issues found and filed by the Desktop Release
QA Team last week, August 22 - August 26 (week 34).



Additional details on the team's priorities last week, as well as
the plans for the current week are available at:

https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus




RELEASE CHANNEL

none



  BETA CHANNEL


  

  ID
  Summary
  Product
  Component
  Is
a regression
  Assigned
to


  1297632

  
  [OSX
10.12] Safe Browsing Phising warning is not displayed

  
  Toolkit

  
  Safe
Browsing

  
  NO
  NOBODY

  



AURORA CHANNEL


  

  ID
  Summary
  Product
  Component
  Is
a regression
  Assigned
to


  1298027

  
  [EME]
Video is crashing on Shaka Player Demo page when is moved
into New window

  
  Core

  
  Audio/Video:
Playback

  
  NO
  Bryce
Van Dyk

  


  1298030

  
  [EME]
Video is stuck on Youtube when is moved into New window

  
  Core

  
  Audio/Video:
Playback

  
  NO
  Bryce
Van Dyk

  

  



NIGHTLY CHANNEL


  

  ID
  Summary
  Product
  Component
  Is
a regression
  Assigned
to


  1297040

  
  WebRTC
permission doorhanger doesn't appear while RDM is enabled

  
  Firefox

  
  Developer
Tools: Responsive Design Mode

  
  NO
  NOBODY


  1297336

  
  Device
permission gone from the permission dropdown after detaching
the tab to a new window

  
  Firefox

  
  Device
Permissions

  
  YES
  NOBODY

  



ESR CHANNEL

none





Regards,

Andrei

  


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