Re: A reminder about MOZ_MUST_USE and [must_use]

What would actually be very helpful would be a way to selectively turn on checking of *all* return values in a given file/subdirectory. Is there some mechanism/plan for that? Thanks, -Ekr On Thu, Jan 19, 2017 at 2:09 PM, Nicholas Nethercote wrote: > Hi, > > We have two annotations that can be

Re: Redirecting http://hg.mozilla.org/ to https://

Yes. Kill it with fire! -Ekr On Fri, Jan 27, 2017 at 7:17 AM, Gregory Szorc wrote: > It may be surprising, but hg.mozilla.org is still accepting plain text > connections via http://hg.mozilla.org/ and isn't redirecting them to > https://hg.mozilla.org/. > > On February 1 likely around 0800 PST

Re: Should &&/|| really be at the end of lines?

On Thu, Feb 16, 2017 at 11:39 PM, David Major wrote: > One thing I like about trailing operators is that they tend to match > what you'd find in bullet-point prose. Here's a made-up example: > > You can apply for a refund of your travel insurance policy if: > * You cancel within 7 days of purchas

Re: Should &&/|| really be at the end of lines?

On Fri, Feb 17, 2017 at 4:24 PM, ISHIKAWA,chiaki wrote: > > Point 5: We should set up a "Flag Day" to convert the source tree into the > official format THAT IS SUPPORTED by the mechanical converter/formater, and > change the source code in one sweep. > This seems like it places an enormous amou

Re: Should &&/|| really be at the end of lines?

On Sat, Feb 18, 2017 at 1:10 AM, Jean-Yves Avenard wrote: > > > On 17/02/17 23:18, gsquel...@mozilla.com wrote: > >> Hi again Nick, >> >> Someone made me realize that I didn't fully read your message, sorry for >> that. >> >> I now see that as well as &&/||, you have grepped for other operators,

Re: Please write good commit messages before asking for code review

I'm in favor of good commit messages, but I would note that current m-c convention really pushes against this, because people seem to feel that commit messages should be one line. Not sure what to do about that, but thought I would mention it. -Ekr On Thu, Mar 9, 2017 at 12:10 PM, Boris Zbarsky

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly wrote: > On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote: > > > On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: > > > I review a large number of patches on a typical day, and usually I have > > to > > > spend a fair amount of time to jus

Re: The future of commit access policy for core Firefox

First, let me state that I am generally in support of this type of change. More comments below. On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor wrote: > (please direct followups to dev-planning, cross-posting to governance, > firefox-dev, dev-platform) > > > Nearly 19 years after the creation of th

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 2:53 PM, Ben Kelly wrote: > > > On Thu, Mar 9, 2017 at 5:48 PM, Eric Rescorla wrote: > >> >> >> On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly wrote: >> >>> (Just continuing the thread here.) >>> >>> Persona

Re: The future of commit access policy for core Firefox

On Thu, Mar 9, 2017 at 3:11 PM, wrote: > On Friday, March 10, 2017 at 10:53:50 AM UTC+13, Mike Connor wrote: > > (please direct followups to dev-planning, cross-posting to governance, > > firefox-dev, dev-platform) > > > > > > Nearly 19 years after the creation of the Mozilla Project, commit acce

Re: The future of commit access policy for core Firefox

On Fri, Mar 10, 2017 at 7:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: > On 03/10/2017 12:59 AM, Bobby Holley wrote: > >> At a high level, I think the goals here are good. >> >> However, the tooling here needs to be top-notch for this to work, and the >> standard approach of

Re: The future of commit access policy for core Firefox

On Fri, Mar 10, 2017 at 9:03 PM, L. David Baron wrote: > On Friday 2017-03-10 19:33 -0800, Eric Rescorla wrote: > > We have been using Phabricator for our reviews in NSS and its interdiffs > > work pretty well > > (modulo rebases, which are not so great), and it's

Re: The future of commit access policy for core Firefox

On Mon, Mar 13, 2017 at 12:22 AM, Frederik Braun wrote: > On 12.03.2017 04:08, Cameron Kaiser wrote: > > On 3/10/17 4:38 AM, Masatoshi Kimura wrote: > >> On 2017/03/10 6:53, Mike Connor wrote: > >>> - Two-factor auth must be a requirement for all users approving or > >>> pushing a change.

Re: Revocation protocol idea

There seem to be three basic ideas here: 0. Blacklisting at the level of API rather than site. 1. Some centralized but democratic mechanism for building a list of misbehaving sites. 2. A mechanism for distributing the list of misbehaving sites to clients. As Jonathan notes, Firefox already has a

Re: Revocation protocol idea

On Fri, Mar 31, 2017 at 4:20 AM, Salvador de la Puente < sdelapue...@mozilla.com> wrote: > Hi Eric > > On Wed, Mar 22, 2017 at 6:11 AM, Eric Rescorla wrote: > >> There seem to be three basic ideas here: >> >> 0. Blacklisting at the level of API rather t

Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

On Thu, Apr 6, 2017 at 5:26 AM, Ehsan Akhgari wrote: > On Thu, Apr 6, 2017 at 12:57 AM, L. David Baron wrote: > > > On Thursday 2017-04-06 00:33 -0400, Ehsan Akhgari wrote: > > > In general, I should also say that designing features with > > > fingerprinting in mind is *extremely* difficult and

Re: Quantum Flow Engineering Newsletter #5

On Tue, Apr 18, 2017 at 4:19 AM, Jack Moffitt wrote: > > Another really nice effort that is starting to unfold and I'm super > excited > > about is the new Photon performance project > > , which is a > focused > > effort on the front-end perfo

Re: Ambient Light Sensor API

Going back to Jonathan's (I think) question. Does anyone use this at all in the field? -Ekr On Tue, Apr 25, 2017 at 6:10 AM, Kurt Roeckx wrote: > On 2017-04-25 00:04, Martin Thomson wrote: > > I think that 60Hz is too high a rate for this. > > > > I suggest that we restrict this to top-level,

Re: Ambient Light Sensor API

This suggests that maybe we could just turn it off On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt wrote: > On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: > >> Going back to Jonathan's (I think) question. Does anyone use this at all >> in >> the field? >

Re: Ambient Light Sensor API

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 &

Re: Ambient Light Sensor API

in information theft pretty seriously. -Ekr > On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla wrote: > >> >> >> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente < >> sdelapue...@mozilla.com> wrote: >> >>> The article says: >>> &g

Re: Ambient Light Sensor API

On Wed, Apr 26, 2017 at 2:01 AM, Gervase Markham wrote: > On 25/04/17 16:46, Eric Rescorla wrote: > > This suggests that maybe we could just turn it off > > It would be sad to remove a capability from the web platform which > native apps have. I'm not sure why it would

Re: Ambient Light Sensor API

On Thu, Apr 27, 2017 at 11:02 PM, Frederik Braun wrote: > On 28.04.2017 05:56, Ehsan Akhgari wrote: > > On 04/27/2017 08:09 AM, Frederik Braun wrote: > >> On 27.04.2017 13:56, smaug wrote: > >>> On 04/25/2017 04:38 PM, Ehsan Akhgari wrote: > On 04/24/2017 06:04 PM, Martin Thomson wrote: > >>

Re: Using references vs. pointers in C++ code

As Henri indicates, I think the use of references is consistent with the style guide. It's also worth noting that if you are using boxed pointers, then you almost certainly want to use references to pass them around. I.e., foo(const RefPtr& mPtr); // avoids useless ref count foo(con

Re: Improving visibility of compiler warnings

On Sat, May 20, 2017 at 1:16 PM, Kris Maglione wrote: > On Sat, May 20, 2017 at 08:36:13PM +1000, Martin Thomson wrote: > >> On Sat, May 20, 2017 at 4:55 AM, Kris Maglione >> wrote: >> >>> Can we make some effort to get clean warnings output at the end of >>> standard >>> builds? A huge chunk of

Re: Race Cache With Network experiment on Nightly

What's the state of pref experiments? I thought they were not yet ready. -Ekr On Thu, May 25, 2017 at 7:15 AM, Benjamin Smedberg wrote: > Is there a particular reason this is landing directly to nightly rather > than using a pref experiment? A pref experiment is going to provide much > more re

Re: Improving visibility of compiler warnings

I'd like to second Ehsan's point, but also expand upon it into a more general observation. As it becomes progressively more difficult to build Firefox without mach, it becomes increasingly important that mach respect people's workflows. For those of us who were comfortable with make and the behavi

Re: Improving visibility of compiler warnings

On Fri, May 26, 2017 at 1:50 AM, Gregory Szorc wrote: > On Thu, May 25, 2017 at 7:43 AM, Eric Rescorla wrote: > >> I'd like to second Ehsan's point, but also expand upon it into a more >> general observation. >> >> As it becomes progressively more diffic

Re: Restricting the Notifications API to secure contexts

This seems fine. -Ekr On Mon, Aug 7, 2017 at 6:45 AM, Anne van Kesteren wrote: > Chrome wants to restrict the Notifications API > https://notifications.spec.whatwg.org/ to secure contexts: > > https://github.com/whatwg/notifications/issues/93 > https://github.com/w3c/web-platform-tests/pul

Re: Proposed W3C Charter: WebVR Working Group

On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz wrote: > On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron wrote: > > > I still think opposing this charter because the group should still > > be in the incubation phase would be inconsistent with our shipping > > and promotion of WebVR. > > > > ​I ag

Re: Proposed W3C Charter: WebVR Working Group

. > > > > > > Thus point 3 - we should openly advocate for the proposed charter to > > > be withdrawn and rewritten accordingly. > > > > > > > > > > I'll try to get on the phone with folks to find out more and get > > > something >

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 1:21 AM, Sylvestre Ledru wrote: > > Le 30/08/2017 à 08:53, Henri Sivonen a écrit : > > Regardless of the outcome of this particular style issue, where are we > > in terms of clang-formatting all the non-third-party C++ in the tree? > > We have been working on that but we d

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 9:29 AM, Sylvestre Ledru wrote: > Le 30/08/2017 à 17:25, Eric Rescorla a écrit : > > > > On Wed, Aug 30, 2017 at 1:21 AM, Sylvestre Ledru > wrote: > >> >> Le 30/08/2017 à 08:53, Henri Sivonen a écrit : >> > Regardless of the out

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Wed, Aug 30, 2017 at 3:55 PM, Michael Smith wrote: > Hi everyone, > > Mozilla DevTools is exploring implementing parts of the Chrome DevTools > Protocol ("CDP") [0] in Firefox. This is an HTTP, WebSockets, and JSON > based protocol for automating and inspecting running browser pages. > > Origi

Re: Coding style: `else for` or `else { for... }`?

On Wed, Aug 30, 2017 at 4:41 PM, Jeff Gilbert wrote: > IMO: Never else-for. (or else-while) > > Else-if is a reasonable continuation of concept: "Well it wasn't that, > what if it's this instead?" > Else-for is just shorthand for "well it wasn't that, so let's loop > over something". > > Else-if

Re: Intent to require `mach try` for submitting to Try

What happens if you are using git? -Ekr On Fri, Sep 15, 2017 at 3:30 PM, Gregory Szorc wrote: > The Try Service ("Try") is a mechanism that allows developers to schedule > tasks in automation. The main API for that service is "Try Syntax" (e.g. > "try: -b o -p linux -u xpcshell"). And the tran

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc wrote: > On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla wrote: > >> What happens if you are using git? >> > > git-cinnabar is already supported. > Supported how? Do I have to have special remote names? Special refs?

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc wrote: > On Fri, Sep 15, 2017 at 8:37 PM, Eric Rescorla wrote: > >> >> >> On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc wrote: >> >>> On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla wrote: >

Re: Intent to require `mach try` for submitting to Try

On Sun, Sep 17, 2017 at 12:09 PM, Steve Fink wrote: > On 9/16/17 6:43 AM, Eric Rescorla wrote: > >> On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc wrote: >> >> >> I'd prefer to take a data-driven approach to answering the question of "do >>> we

Re: Intent to require `mach try` for submitting to Try

On Mon, Sep 18, 2017 at 1:10 AM, Henri Sivonen wrote: > On Mon, Sep 18, 2017 at 6:05 AM, Eric Rescorla wrote:> > I don't think that's true, for the reasons I indicated above. Rather, > > there's a policy decision about whether we are going to have Git as a >

Re: Intent to require `mach try` for submitting to Try

On Mon, Sep 18, 2017 at 2:56 AM, James Graham wrote: > On 18/09/17 04:05, Eric Rescorla wrote: > > But that's just a general observation; if you look at this specific case, >>> it might not be much effort to support native git for richer/future try >>> pushing

Re: Intent to require `mach try` for submitting to Try

On Tue, Sep 19, 2017 at 8:40 AM, Aki Sasaki wrote: > On 9/16/17 6:43 AM, Eric Rescorla wrote: > >> 2. There are a lot more people writing code for Firefox than developing >> the >> internal tools, so in general, costs on those people should be avoided. > > >

Re: Intent to require `mach try` for submitting to Try

On Tue, Sep 19, 2017 at 9:20 AM, Andrew McCreight wrote: > On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla wrote: > > > Generally no, but this is an unfortunate consequence of Mozilla's > decision > > a while ago to pick a VCS which has not turned out to be the domina

Re: Intent to require `mach try` for submitting to Try

On Tue, Sep 19, 2017 at 10:21 AM, Eric Rescorla wrote: > > On Tue, Sep 19, 2017 at 9:20 AM, Andrew McCreight > wrote: > >> On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla wrote: >> >> > Generally no, but this is an unfortunate consequence of Mozilla's >

Re: Hiding 'new' statements - Good or Evil?

On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote: > On 11/23/2017 11:54 PM, Botond Ballo wrote: > >> I think it makes sense to hide a 'new' call in a Make* function when >> you're writing an abstraction that handles allocation *and* >> deallocation. >> >> So MakeUnique makes sense, because UniquePtr

Re: Hiding 'new' statements - Good or Evil?

On Mon, Nov 27, 2017 at 4:07 PM, smaug wrote: > On 11/28/2017 12:53 AM, Jeff Gilbert wrote: > >> ranged-for issues are the same as those for doing manual iteration, >> > It is not, in case you iterate using > for (i = 0; i < foo.length(); ++i) > And that is the case which has been often converted

Re: Hiding 'new' statements - Good or Evil?

On Mon, Nov 27, 2017 at 6:41 PM, Xidorn Quan wrote: > On Tue, Nov 28, 2017, at 11:45 AM, Eric Rescorla wrote: > > On Mon, Nov 27, 2017 at 4:07 PM, smaug wrote: > > > And auto makes code reading harder. It hides important information like > > > lifetime management. &

Re: Intent to ship WebRTC RTCRtpReceiver contributing and synchronization sources

Can you explain why you think this is an increased fingerprinting surface? The data in question here is the audio level of *incoming* media, and as the bug indicates, there are other ways to obtain it. -Ekr On Thu, Dec 7, 2017 at 3:41 PM, Tanvi Vyas wrote: > Is there a pref to turn this added

Re: Proposed W3C Charter: Second Screen Working Group

LGTM! On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron wrote: > So I think Martin, Peter, and I share similar concerns here, and I'm > inclined to turn those concerns into an objection to this charter. > > So how does this sound for proposed comments on the charter > (submitted as a formal objecti

Re: Password autofilling

On Tue, Jan 9, 2018 at 8:43 AM, Gervase Markham wrote: > On 01/01/18 20:08, Jonathan Kingston wrote: > > A recent research post[1] have highlighted the need for Firefox to > disable > > autofilling of credentials. The research post suggests web trackers are > > using autofilling to track users ar

Re: Intent to Ship - Support already-enrolled U2F devices with Google Accounts for Web Authentication

On Tue, Jan 30, 2018 at 8:49 AM, J.C. Jones wrote: > Summary: Support already-enrolled U2F devices with Google Accounts for Web > Authentication > > Web Authentication is on-track to ship in Firefox 60 [1], and contains > within it support for already-deployed USB-connected FIDO U2F devices, and

Re: Commit messages in Phabricator

On Mon, Feb 12, 2018 at 6:09 AM, Boris Zbarsky wrote: > On 2/11/18 3:57 PM, Emilio Cobos Álvarez wrote: > >> Arc wants to use something like: >> > > So from my point of view, having the bug# easily linked from various > places where the short summary is all that's shown (pushlogs especially) is >

Re: Is super-review still a thing?

On Fri, Apr 20, 2018 at 7:03 PM, Dave Townsend wrote: > Presumably it supports multiple reviews for a patch, in which case I think > we're fine. > It does. -Ekr > On Fri, Apr 20, 2018 at 3:03 PM Gregory Szorc wrote: > > > On Fri, Apr 20, 2018 at 2:51 PM, L. David Baron > wrote: > > > > > On

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

On Fri, May 11, 2018 at 4:06 PM, Gregory Szorc wrote: > On Wed, May 9, 2018 at 11:01 AM, Ted Mielczarek > wrote: > > > On Wed, May 9, 2018, at 1:11 PM, L. David Baron wrote: > > > > mozregression won't be able to bisect into inbound branches then, > but I > > > > believe we've always been expiri

Re: Proposed W3C Charter: Devices and Sensors Working Group

LGTM -Ekr On Fri, May 25, 2018 at 5:23 PM, L. David Baron wrote: > OK, sorry to not get this drafted until too close to the deadline to > be likely to get feedback, but here's what I currently have for > proposed comments that I'll submit on the charter. (If you happen > to be able to get fee

Re: Rust crate approval

On Sat, Jun 30, 2018 at 9:35 AM, Lars Bergstrom wrote: > ​ > > On Fri, Jun 29, 2018 at 8:33 AM, Tom Ritter wrote: > > > > > I know that enumerating badness is never a comprehensive solution; but > > maybe there could be a wiki page we could point people to for things that > > indicate something

Re: Rust crate approval

On Sun, Jul 1, 2018 at 4:56 PM, Xidorn Quan wrote: > On Mon, Jul 2, 2018, at 9:03 AM, Eric Rescorla wrote: > > On Sat, Jun 30, 2018 at 9:35 AM, Lars Bergstrom > > wrote: > > > > > On Fri, Jun 29, 2018 at 8:33 AM, Tom Ritter wrote: > > > > > > &g

Re: open socket and read file inside Webrtc

On Wed, Jul 4, 2018 at 5:24 AM, wrote: > Hi, > I'm very new with firefox (as developer, of course). > I need to open a file and tcp sockets inside webrtc. > I read the following link > https://wiki.mozilla.org/Security/Sandbox#File_System_Restrictions > there is the sandbox that does not permit t

Re: PSA: Automated code analysis now also in Phabricator

This is amazing and looks super-useful. Really looking forward to seeing what else we can add in this area! -Ekr On Tue, Jul 17, 2018 at 6:22 AM, Jan Keromnes wrote: > TL;DR -- “reviewbot” is now enabled in Phabricator. It reports potential > defects in pending patches for Firefox. > > Last ye

Re: Use of 'auto'

On Tue, Aug 4, 2015 at 8:55 PM, Jeff Walden wrote: > On 08/02/2015 07:17 AM, smaug wrote: > > MakeAndAddRef would have the same problem as MakeUnique. Doesn't really > tell what type is returned. > > For the MakeUnique uses I've added (doubtless many more have popped up > since), I've pretty much

Re: You can now freely mix declarations and statements in all Mozilla C code

On Wed, Sep 9, 2015 at 5:41 PM, Nicholas Nethercote wrote: > Hi, > > In C89 you can't mix declarations and statements, i.e. you have to > declare local variables at the top of a block. C99 relaxed this > annoying restriction, but MSVC did not add support for it for a long > time, so with GCC we c

Re: NPAPI plug-in use case: live video broadcast

On Sat, Sep 19, 2015 at 11:09 AM, Oliver Lietz wrote: > Hi, > our nanoStream plugin supports live encoding and streaming with > h264/aac/rtmp from live camera sources and capture devices. > We needed to replace this with a native extension on Chrome. > WebRTC is a possible future option but not a

Re: Intent to ship: Directory picking and directory drag-and-drop

This seems like a fantastically dangerous feature and ripe for abuse. Are we doing anything in the UI to make very clear to users what's going on? Is there going to be a way to disable it? -Ekr On Mon, Sep 21, 2015 at 8:37 AM, Jonathan Watt wrote: > Targeting Firefox 44 we intend to ship[1] D

Re: Intent to ship: Directory picking and directory drag-and-drop

as, including features we think are bad. -Ekr > That said, if there are ways we can improve the UI here to further > explain to users what is going on, then that sounds good to me. > > / Jonas > > > > On Mon, Sep 21, 2015 at 8:49 AM, Eric Rescorla wrote: > > This s

Re: Intent to ship: Directory picking and directory drag-and-drop

On Mon, Sep 21, 2015 at 3:58 PM, Jonathan Watt wrote: > On 21/09/2015 19:57, Eric Rescorla wrote: > >> On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking wrote: >> >> Note that this, similarly to clipboard integration, is already exposed >>> to the web throug

Re: Intent to ship: Directory picking and directory drag-and-drop

On Mon, Sep 21, 2015 at 8:48 PM, Eric Shepherd wrote: > Eric Rescorla wrote: > > I think there are some fairly obvious issues here, including: > > - There are obvious sensitive files you shouldn't upload under > basically any conditions. > - It's hard

Re: Intent to ship: Directory picking and directory drag-and-drop

On Tue, Sep 22, 2015 at 7:07 AM, Jonas Sicking wrote: > > On Sep 21, 2015 11:57, "Eric Rescorla" wrote: > > > > On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking > wrote: > >> > >> Note that this, similarly to clipboard integration, is already e

Re: NPAPI plug-in use case: live video broadcast

On Fri, Sep 25, 2015 at 3:20 PM, wrote: > On Saturday, September 19, 2015 at 8:15:50 PM UTC+2, Eric Rescorla wrote: > > On Sat, Sep 19, 2015 at 11:09 AM, Oliver Lietz wrote: > > > > > Hi, > > > our nanoStream plugin supports live encoding and streaming with >

Re: NPAPI plug-in use case: live video broadcast

On Tue, Sep 29, 2015 at 3:44 AM, Oliver Lietz wrote: > > > > > > > Firefox WebRTC supports H.264. > Yes but only Baseline profile and not with high quality. > I believe that OpenH264 has started to add some high profile features, but yes, it's not currently HP. Focus is for WebRTC, not for stre

Re: Disabling C++ tests by default?

On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey wrote: > On Thu, Oct 01, 2015 at 10:10:39PM -0700, Gregory Szorc wrote: > > Currently, the Firefox build system builds C++ tests by default. This > adds > > extra time to builds for something that a significant chunk of developers > > don't care about

Re: Disabling C++ tests by default?

On Fri, Oct 2, 2015 at 9:08 AM, Randell Jesup wrote: > >On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey wrote: > > > >> On Thu, Oct 01, 2015 at 10:10:39PM -0700, Gregory Szorc wrote: > >> > Currently, the Firefox build system builds C++ tests by > >> > default. This adds extra time to builds for so

Re: Disabling C++ tests by default?

On Fri, Oct 2, 2015 at 3:31 PM, Mike Hommey wrote: > On Fri, Oct 02, 2015 at 10:01:45AM -0700, Eric Rescorla wrote: > > > Because the win is small, it shouldn't be a priority, but requiring > > > something like --enable-cpp-tests should be ok to do (and of course >

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

On Sun, Oct 11, 2015 at 4:28 AM, Aryeh Gregor wrote: > On Sun, Oct 11, 2015 at 2:09 PM, Aryeh Gregor wrote: > > A new language feature could be used to solve this: allow conversion > > operators to behave differently based on how the variable is declared. > > For instance, it might convert diffe

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

Note: I'm not taking a position on the language feature, just between your two designs. -Ekr On Sun, Oct 11, 2015 at 5:34 AM, Eric Rescorla wrote: > > On Sun, Oct 11, 2015 at 4:28 AM, Aryeh Gregor wrote: > >> On Sun, Oct 11, 2015 at 2:09 PM, Aryeh Gregor wrote: >>

Re: NPAPI plugin use case: native chipcard reader

Well, Firefox now supports WebCrypto. Can you port to that now? -Ekr On Mon, Oct 12, 2015 at 4:13 AM, wrote: > Hi, > > We are working for a bank that implements a plugin for signing login and > transactions in an e-banking solution. This is a key part of the > application, it supports the thre

Re: NPAPI plugin use case: native chipcard reader

On Mon, Oct 12, 2015 at 4:22 AM, Gijs Kruitbosch wrote: > Are you effectively saying that you use crypto for signing financial > transactions, and the PIN is used for authenticating the user but not > involved in the actual signature/crypto algorithm? Therefore, if a user > finds a way to invoke

Re: NPAPI plugin use case: native chipcard reader

On Mon, Oct 12, 2015 at 5:01 AM, Gijs Kruitbosch wrote: > On 12/10/2015 12:34, Eric Rescorla wrote: > >> On Mon, Oct 12, 2015 at 4:22 AM, Gijs Kruitbosch < >> gijskruitbo...@gmail.com> >> wrote: >> >> Are you effectively saying that you use crypto for s

Re: PSA: Local static analysis builds on Linux and Mac OS X

On Wed, Oct 14, 2015 at 6:37 PM, Martin Thomson wrote: > On Wed, Oct 14, 2015 at 6:32 PM, Gregory Szorc wrote: > > As you stated, this helps detect errors earlier during development, which > > is a huge win. Is there a good reason configure doesn't enable the clang > > plugin by default? > > > Y

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander wrote: > > > On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey wrote: > >> Hi, >> >> I started a thread with the same subject almost two years ago. The >> motivation hasn't changed, but the context surely has, so it's probably >> time to reconsider.

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 3:18 PM, Nicholas Alexander wrote: > > > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > >> >> >> On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander < >> nalexan...@mozilla.com> wrote: >> >>> &g

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote wrote: > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > > > > What's needed here is a dependency management system that > > simply builds what's needed regardless of what's changed, > >

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 11:45 AM, Bobby Holley wrote: > On Fri, Oct 23, 2015 at 11:17 AM, Joshua Cranmer 🐧 > wrote: > > Except that to demand contributors don't care about comm-central would be > > to demand of your employees that they should be jerks to the wider > > open-source community. Merg

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc wrote: > On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey wrote: > > > On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote: > > > I support going back to a giant monolithic repository if we can cleanly > > > delineate the code for various

Re: Merging comm-central into mozilla-central

Thanks for clarifying. Based on this, it seems like another way to solve this would be to simply stop worrying about breaking comm-central. Wouldn't that be even easier? -Ekr On Fri, Oct 23, 2015 at 3:38 PM, Gregory Szorc wrote: > On Fri, Oct 23, 2015 at 11:13 PM, Eric Rescorl

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 are now piling into the > > > bug pointing out that trying to find

Re: Dan Stillman's concerns about Extension Signing

threat model point I made below. > With add-on singing fully implemented, if (when) malicious add-ons get > automatically signed, you'll have several more effective tools to deal with > them, compared to the status quo. > Yes. -Ekr > Gavin > > On Nov 27, 2015

Re: Dan Stillman's concerns about Extension Signing

On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch wrote: > On 27/11/2015 23:46, dstill...@zotero.org wrote: > >> The issue here is that this new system -- specifically, an automated >> scanner sending extensions to manual review -- has been defended by >> Jorge's saying, from March when I first br

Re: Dan Stillman's concerns about Extension Signing

How odd that your e-mail was in response to mine, then. -Ekr On Sat, Nov 28, 2015 at 11:34 AM, Gavin Sharp wrote: > I wasn't suggesting that you had made that incorrect assumption. > > Gavin > > On Sat, Nov 28, 2015 at 10:31 AM, Eric Rescorla wrote: > >> On

Re: Dan Stillman's concerns about Extension Signing

s I asked for need to be restricted, and those are all that is needed to evaluate the question at hand. -Ekr > > On Sat, Nov 28, 2015 at 10:35 AM, Eric Rescorla wrote: > > On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch < > gijskruitbo...@gmail.com> > > wrote:

Re: Dan Stillman's concerns about Extension Signing

On Sat, Nov 28, 2015 at 5:28 PM, Mike Hoye wrote: > On 2015-11-28 2:40 PM, Eric Rescorla wrote: > >> How odd that your e-mail was in response to mine, then. >> >> Thanks, super helpful, really moved the discussion forward, high five. Glad I could help. To Ehsan'

Re: Intent to implement and ship: FIDO U2F API

Hi Freddie, glad to see people so excited about it. On Wed, Dec 2, 2015 at 8:22 AM, wrote: > > So, let's forget about 2 for now, it is not a real thing... and > well.. let's forget it. (If you read both specs you should see > real differences and problems...) > > There are probably other question

Re: Intent to implement and ship: FIDO U2F API

On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan wrote: > On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla wrote: > >> Are you thinking of something like WebUSB? >> (https://reillyeon.github.io/webusb/)? This is something we've looked at >> a bit but we'r

Re: Intent to implement and ship: FIDO U2F API

On Wed, Dec 2, 2015 at 1:11 PM, Frederic Martin wrote: > > > There are probably other questions Mozilla Core Team should ask to > > > themselves : > > > > > > - Having a greater/larger HID Support, outside the FIDO U2F scope ? > > > (This allows web services to communicate with HID devices - i.e.

Re: WebUSB

On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan wrote: > On Wed, Dec 2, 2015 at 10:00 AM, Eric Rescorla wrote: > >> On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan >> wrote: >> >> I'd really like to see WebUSB with USB device IDs are bound to

Re: WebUSB

r On Fri, Dec 4, 2015 at 2:25 PM, Robert O'Callahan wrote: > On Fri, Dec 4, 2015 at 1:56 PM, Eric Rescorla wrote: > >> On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan >> wrote: >> >>> There are three possible approaches I can see to expose USB dev

Re: WebUSB

On Thu, Dec 10, 2015 at 1:36 AM, Martin Thomson wrote: > On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan > wrote: > > On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla wrote: > > > >> (4) Have the APIs hidden behind access controls that need to be enabled &g

Re: WebUSB

On Mon, Dec 14, 2015 at 8:02 PM, Robert O'Callahan wrote: > On Mon, Dec 14, 2015 at 9:29 PM, Eric Rescorla wrote: > >> On Thu, Dec 10, 2015 at 1:36 AM, Martin Thomson wrote: >> >>> On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan >>> wro

Re: WebUSB

On Mon, Dec 14, 2015 at 8:15 PM, Robert O'Callahan wrote: > On Mon, Dec 14, 2015 at 11:09 PM, Eric Rescorla wrote: > >> This is certainly something one could consider, but it it seems like it >> confers a major >> advantage on the vendor vis-a-vis everyone else. If

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 9:31 AM, Bobby Holley wrote: > On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes > wrote: > > > Hey Daniel, > > > > Thanks for the heads-up. This is a useful thing to keep in mind as we > work > > through the SHA-1 deprecation. > > > > To be honest, this seems like a net pos

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 9:47 AM, Mike Hoye wrote: > On 2016-01-04 12:31 PM, Bobby Holley wrote: > >> By "this sort of software" do you mean "Firefox"? Because that's what 95% >> of our users experiencing this are going to do absent anything clever on >> our end. We clearly need to determine the sc

  1   2   3   >