Since encryption can be somewhat CPU intensive, if we're encrypting
a large number of strings we want to be able to do so in a background
thread. This will be consumed by the profile migrators when importing
logins.
MozReview-Commit-ID: JoJGOgMzZ4u
--HG--
extra : rebase_source : 4677482b4e9b1df7c7ca70a0e817204ef6638cdf
This patch also adds the capitalization patch file to the chromium patches
MozReview-Commit-ID: BzAkEtCKAi4
--HG--
extra : rebase_source : 8f24d2b855e721f354f12b0d3fca5783cc66702e
Enable sandbox read access extensions to allow content processes
to access fonts stored in non-standard locations without whitelisting
hardcoded directories. This is needed for configurations with third
party font managers that store fonts in their own directories or
user-specified directories.
Now that font access is not dependent on the filename extension
such as .otf and .ttf, remove the relevent tests.
MozReview-Commit-ID: 8hSMrocGwIm
--HG--
extra : rebase_source : b757480398e3f0d9720ab845e9f10fb70a794d77
This reverts 6e41201152dd (Bug 1431621) which compiled but did not link.
It also fixes the original issue by removing the stray \ at the end of the
line that was causing the error.
MozReview-Commit-ID: LgaxYK3EOwR
--HG--
extra : rebase_source : 7de3b5126417ea99ff7fee3a809e556b5a2de4a6
This also removes an assertion that was failing under external sandboxes
that deny unshare() even when it's a no-op.
MozReview-Commit-ID: KBEPJyDGU7M
--HG--
extra : rebase_source : 411a51d7707e506ca8cbe49553ada1de02f7c76b
MinGW doesn't recognize the ui64 prefix, but uLL is equivalent.
MozReview-Commit-ID: Do3hikKzxY7
--HG--
extra : rebase_source : 501e958ce50e95ae1171acc10fb07c28834195d2
error: invalid conversion from 'FARPROC {aka int (__attribute__((__stdcall__)) *)()}' to 'void*' [-fpermissive]
According to http://stackoverflow.com/questions/13958081/, msvc does the fixup
MozReview-Commit-ID: HTghe9uL0EP
--HG--
extra : rebase_source : b083b9247aa07ba58c23b3b3a2e5b19c7393dafb
This also moves those parts of the policy factory out of the constructor,
because the pref service isn't initialized yet at that point.
MozReview-Commit-ID: 6wbq4MHu1GJ
The end goal is to allow the seccomp-bpf policy to vary based on the
content sandbox level.
Rather than add yet another parameter to SetContentProcessSandbox to
pass down the sandbox level, this collects the values that have to be
computed in libxul into a struct, and moves the code that computes it so
it's not cluttering up ContentChild.
MozReview-Commit-ID: L0dyQwHQKhc
On MinGW, these typedefs are the same, and mingw complains about duplicate instantiations.
Rather than use -fpermissive, just comment out the second instantiation.
MozReview-Commit-ID: 5prsrStgwKY
--HG--
extra : rebase_source : 843340df6e2ce835794b4f370f846b249babf93c
Note that MinGW defines it without __builtin_extract_return_addr which
means we're dropping that, but the gcc documentation indicates that
shouldn't be an issue. It is needed when a fixup is necessary:
> For example, on the 31-bit S/390 platform the highest bit has to
> be masked out, or on SPARC platforms an offset has to be added for
> the true next instruction to be executed.
MozReview-Commit-ID: 4D5bIT9Fei4
--HG--
extra : rebase_source : 3f959d72ab3a756e0d636b5eaaf3e883042e9865
This is a small piece of cleanup that turned out to not be strictly
necessary for the rest of this, so I've made it a separate commit.
Sandbox-related launch adjustments (currently, interposing libc
functions and providing a file descriptor for the syscall reporter)
are no longer applied to processes that won't be sandboxed. The
MOZ_SANDBOXED environment variable communicates this to the child
process, which allows SandboxEarlyInit to be skipped in that case as
well. The idea is that disabling sandboxing for a process type, as part
of troubleshooting, should disable everything sandbox-related.
As a side-effect, this also skips some very minor but unnecessary
overhead for NPAPI process startup.
MozReview-Commit-ID: D0KxsRIIRN
--HG--
extra : rebase_source : 89836bea80d0a171324a8e3ff15c6b8e2a163ea9
Before this patch, mozilla::pkix gtests would generate a public/private key pair
and stash it in a global variable. Since this wasn't part of XPCOM nor tracked
by the PSM/NSS shutdown machinery, it wouldn't get released at the appropriate
time. The solution to this is to generate the key and then essentially export it
as data, so no NSS objects are held alive. Since NSS considers private keys
stored in the persistent database sensitive and won't export them in the clear,
we "encrypt" the key material with an empty password so we can import it when
necessary. (While the gtests don't use persistent keys, the test utilties in the
gtests are also used by some xpcshell tests that do use persistent keys, hence
the need to encrypt the key material.)
--HG--
extra : rebase_source : df10c25a462a3ba0396f5ba4a43a52fb924548ff
extra : amend_source : d95722891e49a99c471046cd9c758e914a02838e
Doug Thayer
David Keeler
arthur.iakab
ffxbld
Bob Owen
Tom Ritter
Haik Aftandilian
Cosmin Sabou
Narcis Beleuzu
Margareta Eliza Balazs
Ciure Andrei
Franziskus Kiefer
Jed Davis
Sebastian Hengst
J.C. Jones
Dorel Luca
Alex Gaynor
Gurzau Raul