id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
13721	firefox-78.0esr	ken@…	ken@…	"The second available candidate build for 78.0esr is now available, so before the release next week I'm creating this to document some items of interest.

1. 78.0esr is different from 78.0 in three ways:

· the version is labelled as 78.0esr instead of 78.0

· extensions do not need to be signed by the trusted root (I guess that is for organizations which create their own extensions)

· some nightly options for enabling webrender have been removed, making the tarball slightly smaller.

The nightly options are o convcern, esr cannot be nightly.

Allowing unsigned extensions for the ordinary esr user seems like a bad idea in terms of security: ""Why don't you download and install this handy extension of mine ?"".

Fortunately, it can be fixed with a sed to revert that change:

{{{
sed -i -e 's/Disable/Enable/'      \
 -e '/^MOZ_REQUIRE_SIGNING/s/0/1/' \
 build/mozconfig.common
}}}

As (mostly) noted in the wiki, the accepted build options have changed:

· --disable-webm is no longer accepted, but webm should continue to be recommended because there is a shipped version.

· --disable-startup-noification is no longer accepted, therefore startup-notification becomes required.

· --enable-system-sqlite is no-longer accepted. I guess that after the issue a few moths ago where they were found to be using an internal feature they've decided to keep their own version which works for them. Unlike the situation several year ago where mixing shipped sqlite in firefox and system sqlite in other things apparently caused problems, so far this seems to be ok.

· --with-system-bz2 is no-longer accepted, I assume they've got rid of bz2.

With the first esr candidate I've looked at the difference between using mozilla's preferred clang, clang++ (preferred as in ""one toolchain for all platforms"") and gcc, g++.

On my machine, the build sizes are consistent for each toolchain across several builds. It is not needed to specify the full set of 'CC=clang CXX=clang++ AR=llvm-ar NM=llvm-nm RANLIB=llvm-ranlib' to use clang and clang++ although specifying all does give a slightly smaller and slower build than just using clang and clang++. In either case, the default bfd linker is used.

Traditionally, llvm and therefore clang has been slow to add security hardening. I think that the available hardening flags for x86 (although not for aarch64 and probably not for 32-bit ARM) are now probably the same as in gcc - no idea if they work as well as in gcc, but they seem to be accepted.

So, I tested a series of builds with both gcc, g++ and clang, lang++.

Using gcc, the build and install total 4.9 GB (184 MB installed), using clang the build and install is 77MB smaller at 4.8GB (180 MB installed). I confirmed that neither is using LTO (except that rust code passes -Clto in two places) - that would probably need a PGO build (see Arch) which will take a lot longer.

So, using clang might be a possibility. But repeated tests indicate it is a slower build. Since a BLFS user should (now) expect to update firefox on a 4-weekly cycle, the extra time to build with clang doesn't seem beneficial (and I cannot see that a marginally smaller install will start up noticeably quicker.

Anyway, I did 5 builds of each, with SBU rounded to next unit, and also rounded to three decimals, then averaged.

gcc, rounded to whole SBU 31     33      32      31      32     avg 31.6
and to three decimals     30.98  32.657  31.507  31.418  31.502 avg 31.613

clang, to whole SBU       35     34      33      32      34      avg 33.6
and to three decimals     35.35  33.597  33.326  31.625  33.763  avg 33.532

So the average is 32 SBU with gcc, and 34 SBU with clang.

Yes, this is about 50% slower than firefox-68.9.0.


The webrender items in the diff from 78.0 caused me to look at that: it is still opt-in, but my preliminary tests suggest it can be worthwhile. I've got to do some more tests on a low-end intel (on my haswell i7 it uses typically 20% of 1 cpu, instead of 4 to 5% on ATI R600 and amdgpu), but I epect to add details to the configuration section.


"	enhancement	closed	high	10.0	BOOK	SVN	medium	fixed