As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. But the warning
occurs in third party code, so my hands are tied.
MozReview-Commit-ID: A0UF2RHJzVo
--HG--
extra : rebase_source : 3fc5300f6f67274162f4d65fd83eb9c18b4bf716
This is what Google suggests in its style guide, and somebody
already changed one of these comments to the new style.
--HG--
extra : rebase_source : fe3f7fc17a2fc09ad0ba01fa1511dc8dba7653e1
When building non-gonk builds, ANDROID_VERSION is not set. Beginning with NDK 11, getdtablesize is no longer included. This means that we should use the stub version of the function that is defined in android_stub.h for all android platforms. This patch moves the function out of the "#if ANDROID_VERSION >=21" block so that all android code can use it.
Adding glandium as the reviewer, because he reviewed the original patch at bug 1103816.
MozReview-Commit-ID: 2NmUl5XuvDS
--HG--
extra : transplant_source : %03%8C/%E0%20t%D0%3Al4%D4Oh%CB_%07%8A%24r%CC
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
someone fixes the underlying problem someday. However, there are tons
of ignored warnings in security/certverifier, so I guess the workaround
in this patch is par for the course.
MozReview-Commit-ID: 7GZ9RpkxnwT
--HG--
extra : rebase_source : 023a438b6458fb4859018cde421d51072f0f0490
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. But the warning
occurs in third party code, so my hands are tied.
MozReview-Commit-ID: BCXQcEejre9
--HG--
extra : rebase_source : a36a432edc834ec806dd4341f247143b178902a4
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. But the warning
occurs in third party code, so my hands are tied.
MozReview-Commit-ID: 6n8nl517Ly
--HG--
extra : rebase_source : 19c1c012e1ddf15accbdf1a1050e4d607f9c7b31
There are two parts to this change. The first is a module to drive kinto
collection sync. This gives server-provided last-update times to each module
managing collection information so that data is only fetched when updates are
necessary. This also keeps track of when pings last took place (for future use)
and any apparent difference between client and server clock (we need this later
for the content signing work).
Currently only one module (the kinto version of the OneCRL client) consumes this
information, though more will follow.
The second is a minor change to nsBlocklistService.js to ensure that this ping
takes place whenever the existing blocklist ping happens.
MozReview-Commit-ID: 7SN03AOJ4Wc
When a built-in root certificate has its trust changed from the default value,
the platform has to essentially create a copy of it in the read/write
certificate database with the new trust settings. At that point, the desired
behavior is that the platform still considers that certificate a built-in root.
Before this patch, this would indeed happen for the duration of that run of the
platform, but as soon as it restarted, the certificate in question would only
appear to be from the read/write database, and thus was not considered a
built-in root. This patch changes the test of built-in-ness to explicitly
search the built-in certificate slot for the certificate in question. If found,
it is considered a built-in root.
MozReview-Commit-ID: HCtZpPQVEGZ
--HG--
extra : rebase_source : 759e9c5a7bb14f14a77e62eae2ba40c085f04ccd
When a built-in root certificate has its trust changed from the default value,
the platform has to essentially create a copy of it in the read/write
certificate database with the new trust settings. At that point, the desired
behavior is that the platform still considers that certificate a built-in root.
Before this patch, this would indeed happen for the duration of that run of the
platform, but as soon as it restarted, the certificate in question would only
appear to be from the read/write database, and thus was not considered a
built-in root. This patch changes the test of built-in-ness to explicitly
search the built-in certificate slot for the certificate in question. If found,
it is considered a built-in root.
MozReview-Commit-ID: HCtZpPQVEGZ
--HG--
extra : rebase_source : 898ef37459723f1d8479cfdc58658ccb00e782a9
nsX509CertValidity has several copy-pasted routines that differ only
slightly in the parameters they use for formatting times. Let's have a
single place to do the formatting and pass in the appropriate
parameters.
Before this change, if a certificate's issuer DN did not have an organization
component, nsIX509Cert.issuerOrganization would fall back to using the issuer
common name. This was never a good idea, because this gave misleading
information to consumers of this interface. Furthermore, it appears that all
consumers of this interface already do such a fallback (for display purposes)
when they've determined that it's a reasonable thing to do.
MozReview-Commit-ID: p2gmSP0nZW
--HG--
extra : rebase_source : 2248ff01e8c0e9a79b27f4406fdc2f0a4ed98360
Modify the Mac sandbox to allow temporary files to be created in a
parent-specified subdirectory of NS_OS_TEMP_DIR. This is similar to the
Windows approach. The parent provides a UUID in a preference which is
used by the content process to form the subdirectory name.
MozReview-Commit-ID: 6BONpfZz8ZI
--HG--
extra : rebase_source : ad18e091918356a1a40c13f1453972b4512ad476
This lets us remove things like gotos in the code, and makes resource ownership slightly clearer.
MozReview-Commit-ID: Kucn7exhLd7
--HG--
extra : transplant_source : %27%FF%D2tjLI%9B5ep%21%B7%FA%92%08%14%07%12%C6
Be warned. Do not attemp to change the .js "test" source code in ./js
They are meant to check
- the outdated 0666 octal constant is still parsed correctly,
- the outdated 0666 octal constant raises syntax error flag
in strict mode, etc.
So leave them alone.
It no longer serves any useful purpose:
1. It is no longer possible to add explicit trust for server certs post Bug 825583.
1A. The Add Exception feature is better suited for this anyways.
2. It isn't possible to set explicit distrust in the Cert Manager, only remove explicit trust.
3. Importing may also inadvertently cause verification failures (see Bug 1202636).
From Chromium commit comment:
Sandbox: Add support for file system policies that use implied device paths.
A policy rule of the form \HarddiskVolume0\Foo\bar allows sandboxed code
to use \\.\HarddiskVolume0\Foo\bar directly.
This takes the TLS Error Reporting functionality used in the aboutNetError.xhtml
and aboutCertError.xhtml error pages and moves it to its own component. This
allows us to make use of this same error reporting functionality from elsewhere.
Notably, this allows us to send error reports for issues that occur when loading
subresources.
The xpcshell test included is in security/manager/ssl/tests because we need to
make use of tlsserver functionality from the PSM tests.
Boris Zbarsky
Carsten "Tomcat" Book
Tim Taubert
Bob Owen
Cykesiopka
ffxbld
David Keeler
Gregory Szorc
Brian Smith
Nathan Toone
Nicholas Nethercote
Tooru Fujisawa
Mike Shal
Mark Goodwin
Franziskus Kiefer
Ryan VanderMeulen
Wes Kocher
Richard Barnes
Masatoshi Kimura
Nathan Froyd
Daniel Holbert
sajitk
Kai Engert
Aniket Vyas
Tim Taubert
Haik Aftandilian
Nihanth Subramanya
Ehsan Akhgari
Ben Kelly
ISHIKAWA, Chiaki
Sebastian Hengst
Aidin Gharibnavaz
simplyblue