Age | Commit message (Collapse) | Author |
|
Currently, we use the gtest main for both unittests and e2e tests, which
means that we don't have access to tracing or verbose logging for those
binaries. This patch fixes it by adding a custom test main. This, along
with other issues, has resulted in major inconsistencies in the options
provided by each of our binaries (osp_demo, e2e_tests,
openscreen_unittests, especially), even though they all link against the
same platform implementation.
This patch attempts to fix some of the more frustrating issues with the
options these binaries present, by implementing the following list of
fixes:
1. Move to actually honoring trace logging gn arg, and deletion of the
features.h header since it is unnecessary. This means our trace logging
readme is actually right and you can now actually disable trace logging
by setting the gn arg enable_trace_logging = false.
2. Addition of a custom unit test main. If trace logging is enabled,
-t will toggle it on. If the platform impl is linked (we MUST know this,
as when we are embedded we have no way of setting logging, and this
test main should be used both in embedded and not embedded use cases)
then the log level may be set to verbose by passing -v.
3. The cast_sender, cast_receiver, and osp_demo binaries are cleaned up
to match the flags added to the test main binary. Note that additional
cleanup is warranted on the osp_demo to make it more in line with other
binaries.
Change-Id: I500a46cb118c0721c4c59bd367d3c96d1a542720
Reviewed-on: https://chromium-review.googlesource.com/c/openscreen/+/2168547
Commit-Queue: Jordan Bayles <jophba@chromium.org>
Reviewed-by: Jordan Bayles <jophba@chromium.org>
Reviewed-by: Ryan Keane <rwkeane@google.com>
|
|
This change adds the necessary crypto + messaging steps for a Cast
receiver to authenticate itself as such. It also adds an integration
test that checks our sender authentication code against this receiver
authentication code.
Bug: openscreen:91
Change-Id: If298b8781bc95116714eb36fa68ef96ba82742a3
Reviewed-on: https://chromium-review.googlesource.com/c/openscreen/+/1954745
Commit-Queue: Brandon Tolsch <btolsch@chromium.org>
Reviewed-by: mark a. foltz <mfoltz@chromium.org>
|
|
This change imports cast_auth_util.cc from Chromium's sender component
(//components/cast_channel).
Bug: openscreen:59
Change-Id: I4eb3a66ae1e50dbe0435176a15d13b2c62d452f3
Reviewed-on: https://chromium-review.googlesource.com/c/openscreen/+/1772435
Commit-Queue: Brandon Tolsch <btolsch@chromium.org>
Reviewed-by: Ryan Keane <rwkeane@google.com>
Reviewed-by: Max Yakimakha <yakimakha@chromium.org>
|
|
This change adds cast_crl.cc and supporting files to the
cast_certificate component port. It allows for parsing a revocation
list from a protobuf and using that information as part of verifying a
Cast device's certificate chain.
Bug: openscreen:58
Change-Id: Ia21b52b9951998a57671dd4748da10c3b4be34a6
Reviewed-on: https://chromium-review.googlesource.com/c/openscreen/+/1759270
Reviewed-by: Ryan Keane <rwkeane@google.com>
Reviewed-by: Max Yakimakha <yakimakha@chromium.org>
Commit-Queue: Brandon Tolsch <btolsch@chromium.org>
|
|
This change fixes the remaining TODOs for supporting basic Cast
certificate chain verification according to RFC 5280.
Bug: openscreen:58
Change-Id: Ie779b052470b3872b029ce7a8050dbe2cf1240e8
Reviewed-on: https://chromium-review.googlesource.com/c/openscreen/+/1737531
Reviewed-by: Ryan Keane <rwkeane@google.com>
Reviewed-by: Max Yakimakha <yakimakha@chromium.org>
Commit-Queue: Brandon Tolsch <btolsch@chromium.org>
|
|
This change migrates some of Chromium's //components/cast_certificate
code. Specifically, this change starts the migration by doing basic
certificate chain validation checks. It does not include the revocation
list, as well as a few other final steps for complete verification
support according to RFC 5280.
Change-Id: I3853d4ce831a77a4b71b4f63974d1a156948152f
Reviewed-on: https://chromium-review.googlesource.com/c/openscreen/+/1721328
Commit-Queue: Brandon Tolsch <btolsch@chromium.org>
Reviewed-by: Peter Thatcher <pthatcher@google.com>
Reviewed-by: Max Yakimakha <yakimakha@chromium.org>
|