Re: Dan Stillman's concerns about Extension Signing

On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham wrote: > But the thing is, members of our security group are now piling into the > bug pointing out that trying to find malicious JS code by static code > review is literally _impossible_ (and perhaps hinting that they'd have >

Re: Dan Stillman's concerns about Extension Signing

On 26/11/15 17:13, Mike Hoye wrote: > Stillman wrote some new code and put it through a process meant to catch > problems in old code, and it passed. That's unfortunate, but does it > really surprise anyone that security is an evolving process? That it > might be be full of hard tradeoffs? There

Re: Dan Stillman's concerns about Extension Signing

On 27/11/2015 12:16, Gervase Markham wrote: On 26/11/15 17:13, Mike Hoye wrote: Stillman wrote some new code and put it through a process meant to catch problems in old code, and it passed. That's unfortunate, but does it really surprise anyone that security is an evolving process? That it

Re: Dan Stillman's concerns about Extension Signing

On 27/11/2015 13:41, Frederik Braun wrote: On 27.11.2015 13:16, Gervase Markham wrote: On 26/11/15 17:13, Mike Hoye wrote: Stillman wrote some new code and put it through a process meant to catch problems in old code, and it passed. That's unfortunate, but does it really surprise anyone that

Re: Dan Stillman's concerns about Extension Signing

Hi Am 26.11.2015 um 18:13 schrieb Mike Hoye: > Stillman wrote some new code and put it through a process meant to > catch problems in old code, and it passed. That's unfortunate, but > does it really surprise anyone that security is an evolving process? > That it might be be full of hard

Re: Dan Stillman's concerns about Extension Signing

On 27.11.2015 13:16, Gervase Markham wrote: > On 26/11/15 17:13, Mike Hoye wrote: >> Stillman wrote some new code and put it through a process meant to catch >> problems in old code, and it passed. That's unfortunate, but does it >> really surprise anyone that security is an evolving process? That

Re: Dan Stillman's concerns about Extension Signing

On Friday, November 27, 2015 at 7:59:37 AM UTC-5, Gijs Kruitbosch wrote: > On 27/11/2015 12:16, Gervase Markham wrote: > > On 26/11/15 17:13, Mike Hoye wrote: > >> Stillman wrote some new code and put it through a process meant to catch > >> problems in old code, and it passed. That's unfortunate,

Re: Dan Stillman's concerns about Extension Signing

On 2015-11-27 8:41 AM, Frederik Braun wrote: On 27.11.2015 13:16, Gervase Markham wrote: On 26/11/15 17:13, Mike Hoye wrote: Stillman wrote some new code and put it through a process meant to catch problems in old code, and it passed. That's unfortunate, but does it really surprise anyone that

Re: Dan Stillman's concerns about Extension Signing

On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari wrote: > On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp > wrote: > > > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham > wrote: > > > But the thing is, members of our security group

Re: Dan Stillman's concerns about Extension Signing

On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp wrote: > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham wrote: > > But the thing is, members of our security group are now piling into the > > bug pointing out that trying to find malicious JS code by static

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On 11/27/15 3:16 AM, L. David Baron wrote: (If that is a problem, we could still flush style instead of layout.) We always flush style before onload, because otherwise we wouldn't block onload on things like background images specified in CSS. -Boris

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On 11/27/15 2:15 AM, Axel Hecht wrote: I wonder, how much of the web could rely on this, given our tests do? Our test failures were mostly along the lines of "we expected an assertion here and now we don't get one". I doubt that would much affect the web. -Boris

Re: Dan Stillman's concerns about Extension Signing

The assumption that the validator must catch all malicious code for add-on signing to be beneficial is incorrect, and seems to be what's fueling most of this thread. Validation being a prerequisite for automatic signing is not primarily a security measure, but rather just a way of eliminating

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On 11/27/15 5:33 AM, Vivien Nicolas wrote: But don't we need at least a Flush_Style to make sure the CSS that tries to use background-image will start triggering images decoding and block the onload event ? Yes, we do. That's handled in nsDocLoader::DocLoaderIsEmpty. -Borsi

ESLint is now available in the entire tree

Thanks to some speedy work by Mark Banner and help from Mike Conley, Felipe Gomes and Gijs Kruitbosch we've now landed the changes to make it possible to run "mach eslint" on any directory in the tree. The default rules for the tree are almost non-existent so this is mostly checking for syntax

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On Friday 2015-11-27 08:15 +0100, Axel Hecht wrote: > I wonder, how much of the web could rely on this, given our tests do? What about starting of CSS transitions? Could pages be relying on making a style change in onload starting a transition? Or do other browsers not guarantee that? (If that

Re: Dan Stillman's concerns about Extension Signing

Am 26.11.2015 um 18:14 schrieb WaltS48: > Perhaps you missed. > > Add-ons/Extension Signing - MozillaWiki - > > > I've noticed a couple new items there about how an extension developer > can get their extension signed if it isn't hosted on

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

It may be a stupid question as my understanding of this part of the code is flaky. But don't we need at least a Flush_Style to make sure the CSS that tries to use background-image will start triggering images decoding and block the onload event ? I just want to make sure it won't create