This adds a new net error and cert status for when a connection uses an
obsolete version of TLS (i.e., TLS 1.0 or 1.1 in the default
configuration). This also adds support for the SSLVersionMin enterprise
policy setting which version triggers the error (and will thus show an
interstitial warning), allowing enterprises to opt-out of the legacy TLS
interstitial.
A new interstitial for this error will be added in
https://crrev.com/c/1940707. Support for the control site list will be
added in https://crrev.com/c/1906779.
Bug: 896013, 1039756
Change-Id: Ib24d4b3efcfbbad1f37a41bfed3690280d4d2b71
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1894616
Commit-Queue: Christopher Thompson <cthomp@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736130}
`gn format` recently changed its formatting behavior
for deps, source, and a few other elements when they
are assigned (with =) single-element lists to be consistent
with the formatting of updates (with +=) with single-element.
Now that we've rolled in a GN binary with the change,
reformat all files so that people don't get presubmit
warnings due to this.
This CL was uploaded by me.
Bug: 1041419
Change-Id: I4dc096337fe543a8ff2d027d95323f521989000f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2007768
Reviewed-by: Hans Wennborg <hans@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#732860}
This introduces a new net::Error and two net::CertStatuses that
can be used to signal a known interception certificate is either
detected or blocked (mutually exclusive). The blocking is
implemented via CRLSet, and can thus be provisioned both
in-binary and out-of-band (where dynamic CRLSet updates are
supported).
ERR_CERT_KNOWN_INTERCEPTION_BLOCKED will be set when a
known interception cert has been actively blocked. In addition,
the CertStatuses CERT_STATUS_REVOKED and
CERT_STATUS_KNOWN_INTERCEPTION_BLOCKED are set.
CERT_STATUS_KNOWN_INTERCEPTION_DETECTED will be set when
a known interception cert is detected in the verified chain. It
is a non-error status.
In this revision, if a known interception root is blocked, HSTS
does not cause the error to be fatal/non-overridable. This is
because the error is generated client side, not server-side, and
in the case of Known MITM, there's ambiguous signal of user
intent. Normally, locally-installed anchors would not be blocked
at all (thus not cause any HSTS errors), and this preserves that
element of local-device policy taking priority over the remote
server's preferences.
Because it's implemented via CRLSets, blocking certificates only
works on platforms that integrate CRLSets as part of path
building/verification. However, notification is implemented on
all platforms, as that runs after a certificate path has been
constructed.
Bug: 1014704
Change-Id: I7d20ae4366f04b02fc709a7d2c5e012bda4d0080
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1904545
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Matt Mueller <mattm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#717407}
These tests were previously migrated from single-threaded MessageLoop to
a multi-threaded TaskEnvironment (then named ScopedTaskEnvironment) as
part of crbug.com/891670.
//base OWNERS decided in retrospect that it was better to keep a
single-threaded option for TaskEnvironment and introduced
SingleThreadTaskEnvironment. This CL retrofits that decision for
/components/ssl_errors.
This CL is a no-op if it passes CQ.
This CL was uploaded by git cl split.
R=felt@chromium.org
Bug: 891670
Change-Id: I9965909522968e20f1631f49142d37928cf11a71
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1786982
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Adrienne Porter Felt <felt@chromium.org>
Commit-Queue: Adrienne Porter Felt <felt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693712}
Previously, //net had CertStatus flags which were "errors, but minor", used to
indicate when revocation checking failed or revocation information was
absent. Callers had to check IsCertStatusError and IsCertStatusMinorError to
determine whether this is such a case, which spread this logic all over the source tree,
and callers generally just ignored or automatically bypassed the minor errors.
Furthermore, in some cases revocation checking failing or revocation information being
absent should actually be a real error, not a minor error, but the status code had no way
of indicating that, meaning that hard-fail errors would also be silently bypassed.
Now after crrev.com/c/1766000 the concept of minor cert errors no longer exists, any
cert error should be considered major. If ERR_CERT_NO_REVOCATION_MECHANISM or
ERR_CERT_UNABLE_TO_CHECK_REVOCATION are returned, they should present an error interstitial
or for non-user-visible connections, block the connection.
Bug: 964416
Change-Id: I34bb371ef23f3a1f081a6369ae18b6b40f71e3bc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1769345
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Eric Noyau <noyau@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Reviewed-by: Carlos Knippschild <carlosk@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Commit-Queue: Matt Mueller <mattm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#692737}
This is a reland of 18947083c7
The move_source_file.py script's formatting rules incorrectly
formatted services/device/generic_sensor/platform_sensor_and_provider_unittest_win.cc
after all. But we also can't rely 100% on git cl format (crbug.com/997063)
so I ended up performing a git cl format && git add -up
(+interactive addition of missing blank line after foo.h when included
from top of foo.cc)
Also added
$ tools/git/move_source_file.py net/test/test_with_scoped_task_environment.h net/test/test_with_task_environment.h
Original change's description:
> [TaskEnvironment] Complete migration with header rename
>
> This is merely:
>
> $ tools/git/move_source_file.py base/test/scoped_task_environment.h base/test/task_environment.h
> $ tools/git/move_source_file.py base/test/scoped_task_environment.cc base/test/task_environment.cc
> $ tools/git/move_source_file.py base/test/scoped_task_environment_unittest.cc base/test/task_environment_unittest.cc
> $ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle.h content/public/test/browser_task_environment.h
> $ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle.cc content/public/test/browser_task_environment.cc
> $ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle_unittest.cc content/public/test/browser_task_environment_unittest.cc
> $ tools/git/move_source_file.py ios/web/public/test/test_web_thread_bundle.h ios/web/public/test/web_task_environment.h
> $ tools/git/move_source_file.py ios/web/test/test_web_thread_bundle.cc ios/web/test/web_task_environment.cc
>
> and a few manual renames in DEPS files missed by the script
>
> This CL uses --bypass-hooks to avoid having to git cl format because
> many headers are being reordered by git cl format and it's too many to
> figure out in a no-op CL which ones are okay with it.
> windows.h for one should typically be first and another one of the
> reorderings in PS3 even caused a compile failure:
> https://chromium-review.googlesource.com/c/chromium/src/+/1764962/3/components/services/font/font_loader_unittest.cc
>
> TBR=dcheng@chromium.org
>
> Bug: 992483
> Change-Id: I32a4afd43ef779393c95d9873c157be2d3da1dd1
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1764962
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#689778}
TBR=dcheng@chromium.org
Bug: 992483
Change-Id: I6179dd1329a4d30bf5c65450ea893537f31e6f85
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1767658
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#689794}
This reverts commit 18947083c7.
Reason for revert: broke Win
Original change's description:
> [TaskEnvironment] Complete migration with header rename
>
> This is merely:
>
> $ tools/git/move_source_file.py base/test/scoped_task_environment.h base/test/task_environment.h
> $ tools/git/move_source_file.py base/test/scoped_task_environment.cc base/test/task_environment.cc
> $ tools/git/move_source_file.py base/test/scoped_task_environment_unittest.cc base/test/task_environment_unittest.cc
> $ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle.h content/public/test/browser_task_environment.h
> $ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle.cc content/public/test/browser_task_environment.cc
> $ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle_unittest.cc content/public/test/browser_task_environment_unittest.cc
> $ tools/git/move_source_file.py ios/web/public/test/test_web_thread_bundle.h ios/web/public/test/web_task_environment.h
> $ tools/git/move_source_file.py ios/web/test/test_web_thread_bundle.cc ios/web/test/web_task_environment.cc
>
> and a few manual renames in DEPS files missed by the script
>
> This CL uses --bypass-hooks to avoid having to git cl format because
> many headers are being reordered by git cl format and it's too many to
> figure out in a no-op CL which ones are okay with it.
> windows.h for one should typically be first and another one of the
> reorderings in PS3 even caused a compile failure:
> https://chromium-review.googlesource.com/c/chromium/src/+/1764962/3/components/services/font/font_loader_unittest.cc
>
> TBR=dcheng@chromium.org
>
> Bug: 992483
> Change-Id: I32a4afd43ef779393c95d9873c157be2d3da1dd1
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1764962
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#689778}
TBR=dcheng@chromium.org,gab@chromium.org
Change-Id: I9aa8ff558d1ff78cebe0c25e559c017578ad4f53
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 992483
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1767657
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#689780}
This is merely:
$ tools/git/move_source_file.py base/test/scoped_task_environment.h base/test/task_environment.h
$ tools/git/move_source_file.py base/test/scoped_task_environment.cc base/test/task_environment.cc
$ tools/git/move_source_file.py base/test/scoped_task_environment_unittest.cc base/test/task_environment_unittest.cc
$ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle.h content/public/test/browser_task_environment.h
$ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle.cc content/public/test/browser_task_environment.cc
$ tools/git/move_source_file.py content/public/test/test_browser_thread_bundle_unittest.cc content/public/test/browser_task_environment_unittest.cc
$ tools/git/move_source_file.py ios/web/public/test/test_web_thread_bundle.h ios/web/public/test/web_task_environment.h
$ tools/git/move_source_file.py ios/web/test/test_web_thread_bundle.cc ios/web/test/web_task_environment.cc
and a few manual renames in DEPS files missed by the script
This CL uses --bypass-hooks to avoid having to git cl format because
many headers are being reordered by git cl format and it's too many to
figure out in a no-op CL which ones are okay with it.
windows.h for one should typically be first and another one of the
reorderings in PS3 even caused a compile failure:
https://chromium-review.googlesource.com/c/chromium/src/+/1764962/3/components/services/font/font_loader_unittest.ccTBR=dcheng@chromium.org
Bug: 992483
Change-Id: I32a4afd43ef779393c95d9873c157be2d3da1dd1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1764962
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#689778}
As a final step, replace all includes back:
- mv message_loop_current.h message_loop.h
- s/message_loop_forward.h/message_loop.h/ in all includes.
- s/message_loop_forward.h/message_loop.h/ in base/BUILD.gn
- Remove message_loop_forward.h from third_party/DEPS.
TBR=gab@chromium.orgR=gab@chromium.org
BUG=891670
Change-Id: I623077025701459ddb7045cbcfdad138aa90a9e4
Reviewed-on: https://chromium-review.googlesource.com/c/1313110
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604690}
To facilitate splitting MessageLoop into MessageLoop and MessageLoopImpl
introduce message_loop_forward.h and use it everywhere.
- s/message_loop.h/message_loop_forward.h/ in all includes.
- Add message_loop_forward.h to base/BUILD.gn.
- Add message_loop_forward.h to third_party/DEPS.
TBR=gab@chromium.org
BUG=891670
Change-Id: Ibac3a24f5bd4291c9d57dd32c627477e4e6ef324
Reviewed-on: https://chromium-review.googlesource.com/c/1313108
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604672}
Since the relevant unit tests make real network requests, create
network::TestSharedURLLoaderFactory helper class which is a network-service compatible version of
net::TestURLRequestContextGetter. Use it instead of the one-offs in existing safe-browsing unit tests.
Bug: 844939
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;luci.chromium.try:linux_mojo;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I905f29fda62f9e27905e3705b3d85c64ba13ae94
Reviewed-on: https://chromium-review.googlesource.com/1104795
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568528}
Now that TickClock::NowTicks is a const function, change consumers so
that they hold a const pointer to a clock.
TBR=sky@chromium.org
Bug: None
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_mojo;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I698230dfd458eb7b6d1c4566c6ed8b12db097c0e
Reviewed-on: https://chromium-review.googlesource.com/982621
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547631}
This CL adds a new net error code for legacy Symantec certificates that are
being distrusted in M66 and M70. The net error code will display on the
interstitial, allowing the specific problem to be diagnosed from just a
screenshot of the interstitial. We can also use it to decide when to put a
console message in DevTools.
Because there is code that maps net error -> CertStatus -> net error, this also
requires a new CertStatus flag for the error.
Bug: 815219
Change-Id: Ic15d6c96f8bdef38c26157af13bbf099fee43b70
Reviewed-on: https://chromium-review.googlesource.com/934969
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539439}
If file doesn't use base::WrapUnique, base/memory/ptr_util.h includes
are changed to <memory>.
Bug: 755727
Change-Id: I6fc3a696a2222e140d6d366b2bc9b285fdef2dbc
Reviewed-on: https://chromium-review.googlesource.com/878083
Reviewed-by: Colin Blundell <blundell@chromium.org>
Commit-Queue: Gyuyoung Kim <gyuyoung.kim@lge.com>
Cr-Commit-Position: refs/heads/master@{#531218}
Several call sites incorrectly used GURL::host or GURL::host_piece as an
argument to net::IsLocalhost. This function only expects IPv6 addresses
without brackets. Since the vast majority of the callers start off with
a GURL, change net::IsLocalhost(StringPiece) to net::IsLocalhost(GURL).
For callers that do not have a GURL, and only a host name (e.g. Blink code),
net::HostStringIsLocalhost is added (which behaves like the old net::IsLocalhost).
BUG=797778
TEST=Start Chrome with --allow-insecure-localhost, visit https://[::1]/
and confirm that the site loads without intersitial.
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: Ibb1cbf3f061ea2070d5e479ac4119a813a7e98a7
Reviewed-on: https://chromium-review.googlesource.com/844777
Commit-Queue: Rob Wu <rob@robwu.nl>
Reviewed-by: Eric Roman <eroman@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529180}
In M58, Chrome deprecated fallback to SubjectCN when determining
certificate validity.
This changelist improves the error string shown when a Certificate Name
Mismatch error occurs and the certificate does not specify any DNS
names in the X.509 SubjectAltNames extension.
BUG=708268
Review-Url: https://codereview.chromium.org/2868733003
Cr-Commit-Position: refs/heads/master@{#472468}
In Issue 308330, Chrome deprecated the use of the Subject CN field in
certificate hostname validation. However, the certificate error
interstitial and error classification logic were left unchanged,
leading to misleading error messages and doomed error recovery attempts
in the event that a certificate lacked SubjectAltNames.
In this change, Chrome's Certificate Error interstitial and error
recovery will no longer fallback to the certificate's Subject CN field
when evaluating the certificate's valid dns names.
BUG=703614
Review-Url: https://codereview.chromium.org/2777383002
Cr-Commit-Position: refs/heads/master@{#462230}
This change requires the user of LazyInstance to explicitly select
either ::DestructorAtExit or ::Leaky. It seems clear that many users of
LazyInstance have just gone with default and are either unaware or
didn't consider that the default requires running an AtExit at process
shutdown.
As a first step, make this choice explicit, and update current users
to be ::DestructorAtExit to maintain current behaviour. Follow ups can
then attempt to consider individual switches from DestructorAtExit to
Leaky including reviewers with domain-specific knowledge.
i.e. No intended behaviour change from this CL.
R=thakis@chromium.org
Lots of TBRs for mechanical changes:
boliu: android_webview/
danakj: cc/
dmurph: storage/
jam: content/ ipc/, mojo/
jbauman: gpu/
jochen: gin/
oshima: chromeos/
raymes: ppapi/
rdevlin.cronin: extensions/
rockot: device/, services/
rogerta: google_apis/
rsleevi: net/, crypto/
sdefresne: components/, ios/
sergeyu: jingle/
slan: chromecast/
thakis: base/, chrome/, third_party/, tools/, ui/
vitalybuka: printing/
wez: remoting/
TBR=above
BUG=698982
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_site_isolation;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/2733283002
Cr-Commit-Position: refs/heads/master@{#455405}
The gn and (many!) DEPS changes were lovingly hand-crafted.
The cc changes were done with bash invocations similar to the others
mentioned in the bug.
BUG=401588
Review-Url: https://codereview.chromium.org/2712513004
Cr-Commit-Position: refs/heads/master@{#452591}
Also, this updates the SSLErrorHandler browser tests to use their own
NetworkTimeTracker, instead of the global one. The global one can be
influenced by the field trial config (e.g. might perform a query on startup
before the test has a chance to disable background queries). So the tests
must use their own NetworkTimeTracker to ensure that it behaves as
desired.
BUG=
Review-Url: https://codereview.chromium.org/2653443002
Cr-Commit-Position: refs/heads/master@{#445589}
This CL adds #include "base/threading/thread_task_runner_handle.h" to
any .h/.cc/.cpp/.mm file that contains the string
"ThreadTaskRunnerHandle::" on a line that doesn't start with "//" and
whose corresponding .h file doesn't already contain the include.
.h files are processed first so that the #include is not added to a
.cc/.cpp/.mm file if it is also added to the corresponding .h file.
tools/sort-headers.py was applied to affected files.
TBR=brettw@chromium.org
BUG=675631
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2596283002
Cr-Commit-Position: refs/heads/master@{#440628}
Setting the testing build time ensures that the test passes even if the
system clock is incorrect when running the test.
BUG=668539
Review-Url: https://codereview.chromium.org/2532273003
Cr-Commit-Position: refs/heads/master@{#434835}
This test is flaky. See bug for more info.
BUG=668539
NOTRY=True
TBR=estark
Review-Url: https://codereview.chromium.org/2532623003
Cr-Commit-Position: refs/heads/master@{#434492}
In poking around certificate reports and UMA, I've noticed that
certificate reports give somewhat different data than UMA about how
often the bad clock interstitial is shown. (This is likely due to the
fact that users have to connect to Google over HTTPS to report UMA data,
whereas certificate reports are sent encrypted over HTTP.)
This CL adds a field to the cert report to contain information about
Finch features that affect certificate validation warnings, such as the
network time service experiment. This will allow us to measure the results
of the network time service via cert reports data, not just via UMA.
BUG=659179,589700
TBR=battre@chromium.org
Review-Url: https://codereview.chromium.org/2448943004
Cr-Commit-Position: refs/heads/master@{#431688}
Adding request handlers to the EmbeddedTestServer after it has started
isn't thread safe.
This CL updates some tests so that the EmbeddedTestServer's IO thread
is started after all handlers are added.
BUG=546060
Review-Url: https://codereview.chromium.org/2486313002
Cr-Commit-Position: refs/heads/master@{#431347}
This CL calls NetworkTimeTracker::StartTimeFetch() when a cert date
invalid error is encountered. If network time is not available,
StartTimeFetch() will kick off an on-demand time query, calling a
callback when it completes. Thus, when network time is unavailable,
SSLErrorHandler now waits up to 3 seconds for a time query to complete
before showing an interstitial. This is motivated by the fact that
network time is unavailable (either due to lost sync or due to no
successful time queries) for ~25% of cert date invalid errors.
This is a series of patches to add on-demand time fetches when handling
cert date invalid errors.
CL #1: https://codereview.chromium.org/2447183002/
CL #2: https://codereview.chromium.org/2453523002/
CL #3: https://codereview.chromium.org/2449193002/ <== this one
BUG=589700
Review-Url: https://codereview.chromium.org/2449193002
Cr-Commit-Position: refs/heads/master@{#430720}
GetRegistryLength for host names canonicalizes the input for the caller, but
then returns the length in the canonicalized input, which is not necessarily
the same as the length in the original string. As a result, computations
performed by the caller based on this value can be wrong (see the bug for
more).
All callers of this function were audited and changed to use on of the
following:
- Many callers don't need the offsets. A new function
HostHasRegistryControlledDomain is added to check for the presence of
a R.C.D. without the risk of returning incorrect string lengths.
- Many callers already have guaranteed-canonical strings (they came out of
a GURL or KURL object soon before the call) These were changed to use a
new GetCanonicalHostRegistryLength function. A further advantage is that
these calls will be faster.
- A new Permissive function is added that handles cases where the input
is necessarily non-canonical.
Adds an IDN test case to the unit tests.
Removes checking for IP addresses in the already-known-canonical cases.
This requires a separate full canonicalization and IP addresses should
never match the R.C.D. list.
Reland of https://codereview.chromium.org/2451353002/ with fix which was a
reland of https://codereview.chromium.org/2446273004/ with fix which was a
reland of https://codereview.chromium.org/2433583002/ with fix.
TBR=pkasting@chromium.org
BUG=657199
Review-Url: https://codereview.chromium.org/2456643005
Cr-Commit-Position: refs/heads/master@{#428116}
Reason for revert:
Failing DCHECK_EQ in GetCanonicalHostRegistryLength on WebKit Mac10.11 (dbg) running http/tests/xmlhttprequest/origin-whitelisting-ip-addresses-with-subdomains.html
BUG=659949
Original issue's description:
> Reduce buggy usage of the registry controlled domain service.
>
> GetRegistryLength for host names canonicalizes the input for the caller, but
> then returns the length in the canonicalized input, which is not necessarily
> the same as the length in the original string. As a result, computations
> performed by the caller based on this value can be wrong (see the bug for
> more).
>
> All callers of this function were audited and changed to use on of the
> following:
>
> - Many callers don't need the offsets. A new function
> HostHasRegistryControlledDomain is added to check for the presence of
> a R.C.D. without the risk of returning incorrect string lengths.
>
> - Many callers already have guaranteed-canonical strings (they came out of
> a GURL or KURL object soon before the call) These were changed to use a
> new GetCanonicalHostRegistryLength function. A further advantage is that
> these calls will be faster.
>
> - A new Permissive function is added that handles cases where the input
> is necessarily non-canonical.
>
> Adds an IDN test case to the unit tests.
>
> Removes checking for IP addresses in the already-known-canonical cases.
> This requires a separate full canonicalization and IP addresses should
> never match the R.C.D. list.
>
> Reland of https://codereview.chromium.org/2446273004/ with fix which was a
> reland of https://codereview.chromium.org/2433583002/ with fix.
>
> TBR=pkasting@chromium.org
> BUG=657199
>
> Committed: https://crrev.com/1b0d95acde33777b9b9ab136c35eeefc11a64718
> Cr-Commit-Position: refs/heads/master@{#427908}
TBR=pkasting@chromium.org,brettw@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=657199
Review-Url: https://codereview.chromium.org/2459493002
Cr-Commit-Position: refs/heads/master@{#427984}
GetRegistryLength for host names canonicalizes the input for the caller, but
then returns the length in the canonicalized input, which is not necessarily
the same as the length in the original string. As a result, computations
performed by the caller based on this value can be wrong (see the bug for
more).
All callers of this function were audited and changed to use on of the
following:
- Many callers don't need the offsets. A new function
HostHasRegistryControlledDomain is added to check for the presence of
a R.C.D. without the risk of returning incorrect string lengths.
- Many callers already have guaranteed-canonical strings (they came out of
a GURL or KURL object soon before the call) These were changed to use a
new GetCanonicalHostRegistryLength function. A further advantage is that
these calls will be faster.
- A new Permissive function is added that handles cases where the input
is necessarily non-canonical.
Adds an IDN test case to the unit tests.
Removes checking for IP addresses in the already-known-canonical cases.
This requires a separate full canonicalization and IP addresses should
never match the R.C.D. list.
Reland of https://codereview.chromium.org/2446273004/ with fix which was a
reland of https://codereview.chromium.org/2433583002/ with fix.
TBR=pkasting@chromium.org
BUG=657199
Review-Url: https://codereview.chromium.org/2451353002
Cr-Commit-Position: refs/heads/master@{#427908}
Reason for revert:
compile failure on Cronet Builders
Original issue's description:
> Reduce buggy usage of the registry controlled domain service.
>
> GetRegistryLength for host names canonicalizes the input for the caller, but
> then returns the length in the canonicalized input, which is not necessarily
> the same as the length in the original string. As a result, computations
> performed by the caller based on this value can be wrong (see the bug for
> more).
>
> All callers of this function were audited and changed to use on of the
> following:
>
> - Many callers don't need the offsets. A new function
> HostHasRegistryControlledDomain is added to check for the presence of
> a R.C.D. without the risk of returning incorrect string lengths.
>
> - Many callers already have guaranteed-canonical strings (they came out of
> a GURL or KURL object soon before the call) These were changed to use a
> new GetCanonicalHostRegistryLength function. A further advantage is that
> these calls will be faster.
>
> - A new Permissive function is added that handles cases where the input
> is necessarily non-canonical.
>
> Adds an IDN test case to the unit tests.
>
> Removes checking for IP addresses in the already-known-canonical cases.
> This requires a separate full canonicalization and IP addresses should
> never match the R.C.D. list.
>
> Reland of https://codereview.chromium.org/2433583002/ with fix.
>
> R=pkasting
> BUG=657199
>
> Committed: https://crrev.com/0a8baeebb5bb84e4dc2449c6860f32928eaa6d4c
> Cr-Commit-Position: refs/heads/master@{#427779}
TBR=pkasting@chromium.org,brettw@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=657199
Review-Url: https://codereview.chromium.org/2454813002
Cr-Commit-Position: refs/heads/master@{#427783}
GetRegistryLength for host names canonicalizes the input for the caller, but
then returns the length in the canonicalized input, which is not necessarily
the same as the length in the original string. As a result, computations
performed by the caller based on this value can be wrong (see the bug for
more).
All callers of this function were audited and changed to use on of the
following:
- Many callers don't need the offsets. A new function
HostHasRegistryControlledDomain is added to check for the presence of
a R.C.D. without the risk of returning incorrect string lengths.
- Many callers already have guaranteed-canonical strings (they came out of
a GURL or KURL object soon before the call) These were changed to use a
new GetCanonicalHostRegistryLength function. A further advantage is that
these calls will be faster.
- A new Permissive function is added that handles cases where the input
is necessarily non-canonical.
Adds an IDN test case to the unit tests.
Removes checking for IP addresses in the already-known-canonical cases.
This requires a separate full canonicalization and IP addresses should
never match the R.C.D. list.
Reland of https://codereview.chromium.org/2433583002/ with fix.
R=pkasting
BUG=657199
Review-Url: https://codereview.chromium.org/2446273004
Cr-Commit-Position: refs/heads/master@{#427779}
Reason for revert:
net_unittests failure on Cronet builders
Original issue's description:
> Reduce buggy usage of the registry controlled domain service.
>
> GetRegistryLength for host names canonicalizes the input for the caller, but
> then returns the length in the canonicalized input, which is not necessarily
> the same as the length in the original string. As a result, computations
> performed by the caller based on this value can be wrong (see the bug for
> more).
>
> All callers of this function were audited and changed to use on of the
> following:
>
> - Many callers don't need the offsets. A new function
> HostHasRegistryControlledDomain is added to check for the presence of
> a R.C.D. without the risk of returning incorrect string lengths.
>
> - Many callers already have guaranteed-canonical strings (they came out of
> a GURL or KURL object soon before the call) These were changed to use a
> new GetCanonicalHostRegistryLength function. A further advantage is that
> these calls will be faster.
>
> - A new Permissive function is added that handles cases where the input
> is necessarily non-canonical.
>
> Adds an IDN test case to the unit tests.
>
> Removes checking for IP addresses in the already-known-canonical cases.
> This requires a separate full canonicalization and IP addresses should
> never match the R.C.D. list.
>
> BUG=657199
>
> Committed: https://crrev.com/060f6a0de7706cc43f9d773ae9ce2cb36bc9964d
> Cr-Commit-Position: refs/heads/master@{#427545}
TBR=pkasting@chromium.org,asargent@chromium.org,brettw@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=657199
Review-Url: https://codereview.chromium.org/2454553002
Cr-Commit-Position: refs/heads/master@{#427561}
This CL refactors network_time_test_utils in preparation for enabling
on-demand time fetches when a DATE_INVALID certificate error is
encountered.
The changes are:
1. Make FieldTrialTest no longer inherit from ::testing::Test, so that
it can be used compositionally in tests that subclass
e.g. RenderViewHostTestHarness. (A follow-up CL will use a
FieldTrialTest inside a RenderViewHostTestHarness test.)
2. Add an argument to enable on-demand fetches to
SetNetworkQueriesWithVariationsService(). This param is not yet used
anywhere but will be in follow-up CLs.
3. Move GoodTimeResponseHandler from network_time_tracker_unittest.cc to
network_time_test_utils.h/.cc. A follow-up CL will use this response
handler to test on-demand time fetches outside of
network_time_tracker_unittest.cc.
This is a series of patches to add on-demand time fetches when handling
cert date invalid errors.
CL #1: https://codereview.chromium.org/2447183002/ <== this one
CL #2: https://codereview.chromium.org/2453523002/
CL #3: https://codereview.chromium.org/2449193002/
BUG=589700
Review-Url: https://codereview.chromium.org/2447183002
Cr-Commit-Position: refs/heads/master@{#427551}
GetRegistryLength for host names canonicalizes the input for the caller, but
then returns the length in the canonicalized input, which is not necessarily
the same as the length in the original string. As a result, computations
performed by the caller based on this value can be wrong (see the bug for
more).
All callers of this function were audited and changed to use on of the
following:
- Many callers don't need the offsets. A new function
HostHasRegistryControlledDomain is added to check for the presence of
a R.C.D. without the risk of returning incorrect string lengths.
- Many callers already have guaranteed-canonical strings (they came out of
a GURL or KURL object soon before the call) These were changed to use a
new GetCanonicalHostRegistryLength function. A further advantage is that
these calls will be faster.
- A new Permissive function is added that handles cases where the input
is necessarily non-canonical.
Adds an IDN test case to the unit tests.
Removes checking for IP addresses in the already-known-canonical cases.
This requires a separate full canonicalization and IP addresses should
never match the R.C.D. list.
BUG=657199
Review-Url: https://codereview.chromium.org/2433583002
Cr-Commit-Position: refs/heads/master@{#427545}
The 'interstitial.clockstate.network2' histogram has been recording the
wrong enum, meaning that the reported values were mislabeled, and also
the enum that was actually being histogrammed has changed around
recently. Thus, this CL deprecates the bogus network2 histogram and
replaces it with the network3 histogram that records the correct enum. It
also adds a unit test to check that values for this histogram are properly
recorded.
BUG=589700
Review-Url: https://codereview.chromium.org/2421143002
Cr-Commit-Position: refs/heads/master@{#426035}
For a large percentage of CERT_DATE_INVALID errors, network time is not
available due to no sync, despite an attempt to query for network time
sync as early as possible in browser startup.
This CL modifies/adds UMA histograms to answer two questions:
1. What is the latency of network time fetches? (i.e. would it be
feasible to wait to show the interstitial until a network time query has
completed?)
2. When network time is unavailable due to no sync, is it because a
query hasn't been attempted yet, or because all prior query attempts
have failed, or perhaps because the first query attempt hasn't completed
yet?
BUG=589700
Review-Url: https://codereview.chromium.org/2415703005
Cr-Commit-Position: refs/heads/master@{#425475}
A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.
To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.
Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.
The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
correctly)
3) Add base:: namespace qualifier where missing.
WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.
git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.
BUG=637812
Review-Url: https://codereview.chromium.org/2257793002
Cr-Commit-Position: refs/heads/master@{#415593}
Network time is frequently unavailable when we hit certificate date
errors. This CL histograms additional information about why network time
is unavailable (specifically, whether no time query has been made or
whether the system clock lost sync since the last time query).
To do so, I deprecated the old network time histogram that shared an
enum with the build time histogram, and introduced a new network
time histogram with a network time enum (rather than adding more
network-specific values to the enum that is shared with the build time
histogram).
BUG=
Review-Url: https://codereview.chromium.org/2254433003
Cr-Commit-Position: refs/heads/master@{#415244}