Re: what if to not to give firefox sys_admin capability with apparmor?

On Monday, February 10, 2020 at 11:14:26 AM UTC-7, gcpas...@gmail.com wrote: > IIRC CAP_SYS_ADMIN is needed to install seccomp-bpf filters. We don't need capabilities for seccomp-bpf. We do need capabilities for anything namespace-related: chroot()ing to a deleted directory to revoke filesystem

Re: Intent to deprecate - linux32 tests starting with Firefox 69

jma...@mozilla.com writes: > As our next ESR is upcoming, I would like to turn off linux32 on > Firefox 69 and let it ride the trains and stay on 68 ESR. This will > allow builds/tests to be supported with security updates into 2021. Does this mean that Linux on 32-bit x86 is being demoted to

Re: Performance profiling improvements #3

Mike Hommey writes: > On Mon, Oct 22, 2018 at 02:20:32PM -0700, Panos Astithas wrote: >> To record a profile with the ‘perf’ command run the >> following commands and then load the firefox.symbol.data output file from >> https://perf-html.io: >> > sudo perf record -g -F 999 -p >> > sudo perf

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

Cameron McCormack writes: > (I wonder if we could collect all the same data, and use the same > crash reporting infrastructure, for non-crashing crash reports like > this.) For what it's worth, I've done something very close to this *accidentally*, on Linux, by manually sending a crash signal

Re: Enabling seccomp-bpf for content process on nightly Linux desktop

Ted Mielczarek <t...@mielczarek.org> writes: > On Tue, Jul 5, 2016, at 11:18 PM, Jed Davis wrote: >> (However, there aren't automated >> tests to ensure it keeps working; "crashing the content process" isn't a >> use case that the test framework docs were

Re: Enabling seccomp-bpf for content process on nightly Linux desktop

Steve Fink writes: > On 07/05/2016 01:33 AM, Julian Hector wrote: >> If you encounter a crash that may be due to seccomp, please file a bug in >> bugzilla and block Bug 1280415, we use it to track issues experienced on >> nightly. > > What would such a crash look like? Do they

Re: Enabling seccomp-bpf for content process on nightly Linux desktop

Benjamin Smedberg writes: > Assuming these crashes show up in crash-stats.mozilla.com, are there > particular signatures, metadata, or other patterns that would let us say > "this crash is caused by a sandbox failure"? They should, and the expected distinguishing feature

Re: Static analysis for "use-after-move"?

Kyle Huey writes: > Can we catch this pattern with a compiler somehow? > > Foo foo; > foo.x = thing; > DoBar(mozilla::Move(foo)); > if (foo.x) { /* do stuff */ } https://bugzilla.mozilla.org/show_bug.cgi?id=1186706 ("Consider static analysis for Move semantics") There are

Re: Requiring a try job prior to autolanding to inbound

Adam Roach writes: > My understanding is that the autolander is available only to > developers with Level 3 access, right? Given that this is the same > group of people who can do a manual check-in, I don't see why we would > make autolanding have to clear a higher bar than

Re: HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)

On Thu, Jan 29, 2015 at 06:57:30AM +0900, Mike Hommey wrote: So, in practice, because the h264 code is not sandboxed on some setups, we're disabling it so that vp8, which is not sandboxed either, is used instead. We have about the same amount of control over openh264 and vp8 code bases. What

HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)

Short version: On desktop Linux systems too old to support seccomp-bpf system call filtering[1], Gecko Media Plugins will be disabled; in practice, this means OpenH264, which is used for H.264 video compression in WebRTC. This will be controlled with a pref, media.gmp.insecure.allow. [1]

Re: Non-Trivial SpecialPowers Usage Considered Harmful

Bobby Holley bobbyhol...@gmail.com writes: [...] If you find yourself itching to do something complicated, write a mochitest-chrome test. The default template [2] now generates html files (rather then XUL files), so the ergonomics there should be easier than before. If you don't want to

Re: Deciding whether to change the number of unified sources

On Tue, Dec 03, 2013 at 11:47:48AM -0800, L. David Baron wrote: On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote: Also, I would be very interested in seeing size of libxul.so for fully-optimized (including PGO, where we normally do PGO) builds. Do unified builds help or hurt libxul size

Re: Is there any reason not to shut down bonsai?

On Thu, Nov 21, 2013 at 05:41:27PM -0500, Boris Zbarsky wrote: On 11/21/13 3:15 PM, Gavin Sharp wrote: It would be good to explore alternatives to Bonsai. https://github.com/mozilla/mozilla-central is supposed to have full CVS history, right? Hmm. Where in there is the equivalent of

Re: Code coverage take 2, and other code hygiene tools

On Mon, Jun 24, 2013 at 08:02:26PM -0700, Justin Lebar wrote: Under what circumstances would you expect the code coverage build to break but all our other builds to remain green? Anywhere you're using -Werror. I ran into this in a past life with GCC's may-use-uninitialized warning; if it's

Re: Storage in Gecko

On Mon, May 06, 2013 at 09:41:08AM -0700, David Dahl wrote: KyotoCabinet might make a good backend for a new storage API: http://fallabs.com/kyotocabinet/ It's released under the GPL, so it's MPL-incompatible, if I understand correctly. As for the Kyoto Products Specific FOSS Library Linking

Re: Please upgrade to at least Mercurial 2.5.1

On Thu, Feb 21, 2013 at 11:36:15AM +, Gervase Markham wrote: The Mercurial download page: http://mercurial.selenic.com/downloads/ offers 2.5.1 for Mac and Windows, but no Linux packages. Can guidance be provided as to where to get such things for commonly-run versions of Linux? Debian