The `RandBytes` functions were being placed in the `crypto` namespace,
which collides with Chromium's namespace of the same name. Within,
`RandBytes` was defined with almost-the-same API. Then in Chromium
builds, the Chromium header would be used instead (though somewhat
inconsistently).
This creates a lot of pain for Chromium development as there's a
third-party repository directly depending on headers from Chromium's
source tree, and is against the third-party policies for that reason.
There are a number of other headers that mirror Chromium and are
swapped out in the Chromium build that will cause similar pain, such as:
```
include "crypto/aead.h"
include "crypto/ec_private_key.h"
include "crypto/hkdf.h"
```
This CL provides a template for how to get rid of these header swaps and
give a platform abstraction in nearby instead.
We provide a platform abstraction in `platform/crypto.h` (really in
`platform/implementation/crypto.h`) which is implemented in
`platform/implementation/shared/crypto.cc`. However that implementation
is removed by `#ifdef` when in the Chromium build.
Then, in the Chromium repo, we will add (separately) an implementation
of the same abstraction in `//third_party/nearby/platform_impl` with GN
rules to include it in the build. It will replace the implementation
from the nearby repo.
Copybara import of the project:
--
6ca8099 by danakj <danakj@chromium.org>:
Provide a platform abstraction for RandBytes instead of swapping headers
The `RandBytes` functions were being placed in the `crypto` namespace,
which collides with Chromium's namespace of the same name. Within,
`RandBytes` was defined with almost-the-same API. Then in Chromium
builds, the Chromium header would be used instead (though somewhat
inconsistently).
This creates a lot of pain for Chromium development as there's a
third-party repository directly depending on headers from Chromium's
source tree, and is against the third-party policies for that reason.
There are a number of other headers that mirror Chromium and are
swapped out in the Chromium build that will cause similar pain, such as:
```
include "crypto/aead.h"
include "crypto/ec_private_key.h"
include "crypto/hkdf.h"
```
This CL provides a template for how to get rid of these header swaps and
give a platform abstraction in nearby instead.
We provide a platform abstraction in `platform/crypto.h` (really in
`platform/implementation/crypto.h`) which is implemented in
`platform/implementation/shared/crypto.cc`. However that implementation
is removed by `#ifdef` when in the Chromium build.
Then, in the Chromium repo, we will add (separately) an implementation
of the same abstraction in `//third_party/nearby/platform_impl` with GN
rules to include it in the build. It will replace the implementation
from the nearby repo.
--
9c2654b by danakj <danakj@chromium.org>:
Remove CryptoSpan, use absl::Span
The header swapping of Chromium crypto libraries is
problematic, but absl::Span will convert to base::span
so there's no need for the typedef even without
removing the header swapping yet.
--
df1135d by danakj <danakj@chromium.org>:
Add missing files
--
ab18a15 by danakj <danakj@chromium.org>:
Remove the random_unittest.cc from Swift build
The file moved, so the Swift package needs its path
updated.
--
2038f78 by danakj <danakj@chromium.org>:
Combine crypto unittests into crypto_test.cc
--
f7ad176 by danakj <danakj@chromium.org>:
Add stdint and stddef includes for uint8_t and size_t
--
9f04590 by danakj <danakj@chromium.org>:
Mark the shared crypto implementation compatable_with non_prod
--
18eeafd by danakj <danakj@chromium.org>:
Add IWYU pragma for crypto implementation
PiperOrigin-RevId: 632150866
Fixes a ChromeOS-deadlock during credential refill. The
previous logic blocked the IO thread that ChromeOS is using
to listen for responses from its CredentialStorage layer,
thus preventing it from signaling the latch.
Given that CheckCredentialsAndRefillIfNeeded is meant to
be async (given its continuation-passing style), this CL
avoids any thread trickiness by removing any latch-waiting
within the function. The nice side-effect of this is breaking
up the function into 3 smaller functions, which should
hopefully make it a bit more readable.
//.../g3/credential_storage_impl.cc has its mutex locks
removed -- they otherwise cause deadlocks, and are now
unnecessary.
This CL introduces a CHECK_EQ to ensure that the number of
remaining valid (not-expired) credentials is equal across the
shared and local list. This actually exposed a bug in the
credential_manager_impl_test.cc -- the test was only expiring
a public credential, and not its corresponding private credential.
Thus, the test is also updated in this CL to correctly mark
the first credential of the shared and local list as expired.
PiperOrigin-RevId: 631822135
Imported from GitHub PR https://github.com/google/nearby/pull/2483
This adds the necessary build rules to build with the LDT rust implementation in bazel, currently it is compiled out by a compiler flag.
This also updates the C++ standard to C++20 in order to be compatible with beto-core's targets
Copybara import of the project:
--
b28eabb2be386bfad4d71df94b7dd77fe34b6b13 by Nabil Wadih <nwadih@google.com>:
Bazel build support for building rust and beto-core targets
--
765f8076642bc54c6a500e5f91c942bcfea55b39 by Nabil Wadih <nwadih@google.com>:
Bazel build support for building rust and beto-core targets
--
3658bdc10dbe8f0bb912e233b411b153179a79eb by Nabil Wadih <nwadih@google.com>:
Bazel build support for building rust and beto-core targets
--
65321ef4fcdf9d1cbdfe866bd3364f3701819a9c by Nabil Wadih <nwadih@google.com>:
Bazel build support for building rust and beto-core targets
--
f52590fd46a04d081c7175a1e342212c1e9174cd by Nabil Wadih <nabil.wadih@gmail.com>:
Update validate.yaml
--
eef6b260cb12701e3dee4a2e41a98ad7aa23183b by Nabil Wadih <nabil.wadih@gmail.com>:
Update validate.yaml
--
b47f67138310263003db29cf05b93f2a60fe487e by Nabil Wadih <nwadih@google.com>:
Bazel build support for building rust and beto-core targets
Merging this change closes#2483
PiperOrigin-RevId: 627873727
see bazelbuild/bazel#10472 for more info on why this is needed. Without it, the build will try to use system headers which conflict with project defined headers in this build for boringssl
PiperOrigin-RevId: 627458516
hai007